اگر برای نگه‌داشتن نسخه‌های پروژه، پوشه‌هایی مثل «نسخهٔ نهایی» و «نهایی‌تر» می‌سازید، گیت می‌تواند این کار را منظم کند. گیت تاریخچه‌ای از تغییرات انتخاب‌شده نگه می‌دارد و کمک می‌کند بفهمید چه چیزی، در کدام مرحله و با چه هدفی تغییر کرده است. برای شروع، لازم نیست همان روز اول همهٔ فرمان‌ها یا کار گروهی را یاد بگیرید؛ یک چرخهٔ کوچکِ دیدن، انتخاب و ثبت کافی است.
سه جای متفاوت برای تغییرات
در پوشهٔ کاری فایل را ویرایش می‌کنید. ناحیهٔ staging جایی است که نسخهٔ آمادهٔ ثبت فایل را انتخاب می‌کنید. کامیت نقطه‌ای در تاریخچه است که این انتخاب را همراه پیام ثبت می‌کند. ذخیره‌کردن فایل در ویرایشگر به‌تنهایی کامیت نمی‌سازد. همچنین اجرای git add به معنی فرستادن فایل به اینترنت نیست؛ این فرمان، محتوای فعلی را برای کامیت بعدی آماده می‌کند.
فرض کنید در حال ساخت یک صفحهٔ معرفی هستید. اصلاح عنوان و تغییر رنگ پس‌زمینه می‌توانند دو تغییر مستقل باشند. اگر هر بار یک کار مشخص را ثبت کنید، پیام و مرور تاریخچه معنی روشن‌تری دارند.
یک تمرین در پوشه‌ای تازه
گیت باید از قبل نصب باشد. یک پوشهٔ خالی و آزمایشی بسازید و ترمینال را همان‌جا باز کنید. سپس اجرا کنید:
git init
git status
در ویرایشگر، فایل hello.txt را بسازید و داخلش بنویسید Hello, CodePin. حالا وضعیت را دوباره ببینید، فقط همان فایل را انتخاب کنید و انتخابتان را مرور کنید:
git status
git add hello.txt
git diff --staged
git commit -m "Add greeting example"
git status
اگر گیت هنگام کامیت هویت نویسنده را نداشت، نام و ایمیل مناسب خودتان را برای همین مخزن تنظیم کنید و دوباره کامیت بگیرید. توجه کنید ایمیلِ ثبت‌شده می‌تواند همراه تاریخچهٔ منتشرشده دیده شود:
git config user.name "Your Name"
git config user.email "you@example.com"
این مقادیر نمونه‌اند؛ آن‌ها را بدون تغییر به عنوان هویت خود ثبت نکنید. تنظیم بالا محلی است و به همهٔ مخزن‌های دستگاه اعمال نمی‌شود.
چرا قبل از کامیت دو بار تفاوت را می‌بینیم؟
حالا خط دیگری به hello.txt اضافه کنید. git diff تغییر ثبت‌نشده نسبت به staging را نشان می‌دهد؛ پس از git add hello.txt، فرمان git diff --staged محتوای آمادهٔ کامیت را نشان می‌دهد. اگر بعد از add دوباره فایل را ویرایش کنید، آخرین ویرایش خودبه‌خود وارد staging نمی‌شود.
یک عادت کاربردی این است که پیش از هر کامیت، اول git status و سپس تفاوت staged را بخوانید. در این تمرین به جای git add . نام فایل را نوشته‌ایم تا انتخاب شما آشکار باشد. هدف یادگرفتن مرز تغییر است، نه حفظ‌کردن یک میان‌بر.
چند اشتباه قابل پیشگیری
- فایل رمز، پایگاه دادهٔ واقعی، پوشهٔ محیط مجازی و خروجی موقت را بدون بررسی وارد تاریخچه نکنید.
- پیام‌هایی مثل «تغییرات» یا «درست شد» بعداً کمک کمی می‌کنند؛ هدف تغییر را بنویسید.
- کامیت محلی را با پشتیبان خارج از دستگاه یکی ندانید. فرستادن تاریخچه به مخزن راه‌دور مرحله‌ای جداگانه است.
- برای رفع هر مشکل، سراغ فرمان‌های حذف یا بازنشانی نروید؛ ابتدا خروجی status و diff را بخوانید.
تمرین را وقتی تمام‌شده بدانید که بتوانید توضیح دهید کدام محتوا در فایل فعلی، کدام محتوا در staging و کدام تغییر در آخرین کامیت است. برای آموزش‌های بعدی، بخش ابزارهای توسعهٔ کدپین را دنبال کنید.