git به‌عنوان دکمه‌ی بازگشت

فصل قبل گفت کپی بگیر. حالا مشکلِ کپی: یک کپی، یک نسخه است. وقتی پنج بار پشت سر هم چیزی را عوض کردی و بار پنجم فهمیدی جواب درست همان بار دوم بود، کپی کمکت نمی‌کند — چون نسخه‌ی بارِ دوم را نداری.

و راه‌حل معمولِ آدم‌ها، بدترین راه‌حل است:

قرارداد-نهایی · قرارداد-نهایی-۲ · قرارداد-نهایی-واقعی · قرارداد-نهایی-واقعی-اصلاح‌شده

این هم تاریخچه است، ولی تاریخچه‌ای که ترتیبش را نمی‌دانی، و نمی‌دانی هر نسخه چه فرقی با قبلی داشت.

git — که گیت خوانده می‌شود — همین را حل می‌کند: یک فایل، با تمام تاریخچه‌اش، بدون بیست کپی. اسمش را زیاد شنیده‌ای و احتمالاً به‌عنوان «ابزار برنامه‌نویس‌ها» شناخته‌ای؛ بخش ۵.۲.۵ می‌گوید چرا این برداشت درست نیست.

مدل ذهنی git ساده است. هر بار که یک نسخه ثبت می‌کنی، یک نقطه روی یک خط اضافه می‌شود:

سه چیز که این تصویر می‌گوید و ارزش دقت دارند:

• نقطه‌ها فقط اضافه می‌شوند. ثبتِ نسخه‌ی ۴، نسخه‌ی ۳ را پاک نمی‌کند.
• هر نقطه یک توضیح دارد — «بند مالی اضافه شد». همین توضیح است که تاریخچه را قابل استفاده می‌کند، برخلاف نهایی-۲.
• برگشت، پرش است نه حذف. می‌روی به نسخه‌ی ۲، و نسخه‌ی ۴ هم سر جایش هست.

git ابزار بزرگی است و ده‌ها دستور دارد. برای کاری که ما می‌کنیم، سه تا کافی است — و خبر خوب اینکه لازم نیست حفظشان کنی، چون می‌توانی از ایجنت بخواهی انجامشان دهد. ولی باید بدانی چه کاری می‌کنند، وگرنه نمی‌فهمی داری چه چیزی را تأیید می‌کنی (فصل ۳.۳).

• وضعیت — git status. «از آخرین ثبت تا الان، چه چیزی عوض شده؟» بی‌خطرترین دستور git؛ فقط نگاه می‌کند.
• ثبت — git add . && git commit -m "توضیح". یک نقطه‌ی جدید روی خط. این همان لحظه‌ای است که نسخه «محفوظ» می‌شود. در فارسیِ گفتاری به آن کامیت هم می‌گویند و اگر جایی «کامیت کن» شنیدی، منظور همین است.
• برگشت — git checkout <نسخه>. پرش به یک نقطه‌ی قبلی.

به‌خاطر بسپار git فقط چیزی را نگه می‌دارد که ثبت کرده‌ای. تغییری که ثبت نشده، در تاریخچه نیست — و اگر رویش بنویسند، رفته. پس «git داریم» تنها وقتی محافظت است که قبل از کار جدی ثبت کرده باشی، نه بعدش.

این کل کاربرد git در این دوره است، در یک ترتیب:

1. ثبت کن — یعنی «این وضعیتِ سالم است، به آن برمی‌گردم».
2. کار را به ایجنت بسپار.
3. راستی‌آزمایی کن (فصل ۴.۵).
4. خوب بود؟ ثبت کن. بد بود؟ برگرد.

و چون قدم ۱ ده ثانیه است، هزینه‌ی این محافظت تقریباً صفر است. آن چیزی که خطرناک بود — ندانستن اینکه چطور برمی‌گردی (فصل ۵.۱.۳) — حالا جواب روشنی دارد.

و یک فایده‌ی دوم که کم‌تر گفته می‌شود: وضعیت به تو نشان می‌دهد ایجنت دقیقاً چه چیزی را عوض کرد — نه آنچه گفت عوض کرد. این یکی از تمیزترین راه‌های راستی‌آزمایی است، چون از خودِ ایجنت نمی‌پرسی.

یک تصور غلط رایج: git «برای برنامه‌نویس‌ها» است. نه — git برای فایل متنی است، و فایل متنی فقط کد نیست:

• خوب کار می‌کند: متن ساده، Markdown، CSV، فایل‌های تنظیمات، HTML. برای این‌ها git می‌تواند دقیقاً بگوید کدام خط عوض شده.
• کار می‌کند ولی کور: Word، Excel، PDF، عکس. نگهشان می‌دارد و برگشت هم می‌دهد، ولی نمی‌تواند بگوید داخلشان چه عوض شده — فقط «این فایل عوض شد».

پس برای پوشه‌ای پر از فایل Word هم git بی‌فایده نیست؛ فقط نصفِ فایده‌اش را می‌دهد. و همین نصف — «برگرد به نسخه‌ی سه ثبت قبل» — همان چیزی است که می‌خواستیم.