2026-10-20
فرض کن داری یه پایان‌نامه می‌نویسی. هر بار که تغییری می‌دی، فایل رو با یه اسم جدید ذخیره می‌کنی: «نهایی»، «نهایی۲»، «نهایی-واقعی»، «نهایی-این‌بار-واقعاً-نهایی».
بعد از یه هفته نمی‌دونی کدوم نسخه درسته و کدوم رو اشتباهی پاک کردی.
Git برای حل همین مشکل ساخته شده.
Git یه ابزاره که تاریخچه‌ی تغییرات پروژه‌ات رو نگه می‌داره. هر وقت بخوای می‌تونی برگردی به نسخه‌ی قبلی، ببینی چی عوض شده و کی عوض کرده.
Git مثل دفترچه‌ی یادداشتیه که خودت داری. GitHub مثل یه قفسه‌ی مشترک که همه می‌تونن دفترچه‌ها رو اونجا ببینن. (سایت‌های دیگه‌ای هم مثل GitHub هستن، ولی مفهوم‌ها یکیه.)
یه پوشه‌ی پروژه که Git تاریخچه‌اش رو نگه می‌داره. بهش می‌گن «ریپو».
یه «عکس‌فوری» از پروژه‌ات در یه لحظه، با یه پیام که می‌گه چی عوض شد. مثلاً: «اضافه کردن صفحه‌ی ورود».
نکته: پیام commit رو واضح بنویس. «تغییرات» یا «fix» به درد کسی نمی‌خوره؛ وقتی ۶ ماه بعد دنبال یه باگ می‌گردی، قدر یه پیام خوب رو می‌دونی.
یه «شاخه» که ازش می‌تونی یه نسخه‌ی موازی از پروژه بسازی. مثلاً شاخه‌ی اصلی (main) نسخه‌ی سالمه، و تو برای یه قابلیت جدید یه شاخه‌ی جدا می‌سازی و اونجا آزادانه تغییر می‌دی، بدون اینکه نسخه‌ی اصلی خراب بشه.
وقتی کارت تو شاخه تموم شد، ادغامش می‌کنی با شاخه‌ی اصلی.
اگه دو نفر یه خط از یه فایل رو متفاوت عوض کنن، Git نمی‌دونه کدوم درسته و ازت می‌پرسه. بهش می‌گن Conflict. ترسناک به نظر میاد ولی فقط یه سؤاله: «کدوم نسخه می‌مونه؟»
وقتی می‌خوای کارت رو تو پروژه‌ی تیمی بذاری، یه «درخواست» می‌سازی که بگه «لطفاً این تغییرات رو بررسی کنید و ادغام کنید.» همکارهات کد رو می‌بینن، نظر می‌دن (Code Review) و بعد ادغام می‌شه.
git init # شروع یه ریپوی جدید
git status # ببین چی عوض شده
git add . # تغییرات رو برای commit آماده کن
git commit -m "پیام" # یه commit بزن
git branch اسم-شاخه # شاخه بساز
git switch اسم-شاخه # برو به یه شاخه
git push # بفرست به GitHub
git pull # آخرین تغییرات رو بگیرلازم نیست همه رو حفظ کنی. ۵ تای اول رو که تمرین کنی، بقیه خودبه‌خود جا میفتن.
تقریباً هر تیم برنامه‌نویسی از Git استفاده می‌کنه و تو مصاحبه‌ها هم ازش می‌پرسن. و اگه می‌خوای با ایجنت‌های هوش مصنوعی روی یه پروژه کار کنی، Git راهیه که تغییراتشون رو ببینی و اگه خراب کردن، برگردی.