Git در یک نگاه

گیت (Git)، یک ابزار کنترلِ نسخۀ متن‌باز و قدرتمند برای توسعه‌دهندگان نرم‌افزار و مصنوعاتِ دیجیتال است که در ابتدا توسط لینوس تُروالدز (خالق هستۀ لینوکس) معرفی و توسعه داده شد. کار با گیت بسیار ساده است، به شرطی که آن را خوب درک کرده و البته چند دستور ناقابل را حفظ کرده باشید. در ادامه، دستوراتِ پرکاربرد و چند توصیه در به‌کارگیری از Git را برایتان محیا کرده‌ام.

در کارهای روزانه استفاده از اصطلاحاتِ طناز و بومی برای ابزارهایی مثل گیت، کار را برای همه راحت‌تر می‌کند. یکی از این اصطلاحاتِ که ما در گروه خود از آن استفاده می‌کنید، ترکیبِ «لیستِ پرواز» بجای واژۀ Stage در Git است! 🙂

ایجاد

  1. نسخه گیری یا نمونه‌گیری از یک مخزنِ Git خارجی
  2. ایجادِ یک مخزن Git محلی روی رایانۀ شخصی
ایجاد git

تغییرات محلی

  1. نمایش فایل‌های تغییر کرده در پوشۀ کاری
  2. نمایش تغییراتِ درونِ فایل‌های پوشۀ کاری با نسخه‌ی قبلشان
  3. نمایش تغییراتِ درون فایل‌های لیستِ پرواز با نسخۀ قبلشان
  4. افزودن تمام تغییرات جاری به لیستِ پرواز برای کامیت بعدی
  5. خارج کردن یک فایل از لیستِ پرواز
  6. افزودن بخشی از تغییراتِ یک فایل به لیستِ پرواز برای کامیت بعدی
  7. کامیتِ یکجای همۀ فایل‌های تغییر کرده (بدون نیاز به لیستِ پرواز)
  8. کامیتِ تغییراتِ ثبت‌شده در لیستِ پرواز
  9. ایجاد تغییر در محتوای کامیتِ آخر
تغییرات محلی git

تاریخچۀ کامیت‌ها

  1. نمایشِ فهرستی از کامیت‌ها با اولویت تاریخِ ثبت
  2. نمایش فهرستِ تغییرات صورت گرفته بر روی یک فایل در طول زمان
  3. چه زمانی، چه کسی، چه‌کاری را بر روی یک فایل انجام داده است؟
تاریخچه کامیت ها git

انشعاب‌ها و برچسب‌ها

  1. نمایش فهرستی از انشعاب‌های موجود در Git
  2. تعویض انشعاب کاری (HEAD)
  3. ایجاد یک انشعاب جدید از روی انشعاب کاری
  4. حذف یک انشعاب محلی از Git
  5. برچسب‌زنی به کامیت آخر
انشعاب ها و برچسب ها git

به‌روزرسانی و انتشار

  1. نمایش فهرستی از مخازن Git خارجی (غیر محلی) ثبت‌شده
  2. نمایش اطلاعات مربوط به یک مخزن خارجی ثبت‌شده
  3. ثبتِ یک مخزن خارجی
  4. دانلود تمام تغییرات از مخزن خارجی (بدون تغییر در انشعاب کاری)
  5. دانلود تغییرات از مخزن خارجی و ادغام و یکپارچه‌سازی با انشعاب کاری
  6. انتشار تغییرات محلی بر روی مخزن خارجی
  7. حذف یک انشعاب از روی مخزن خارجی
  8. انتشار برچسب‌های محلی
انتشار

ادغام و تعویض پایه (Rebase)

  1. ادغام یک انشعاب موجود بر روی انشعاب کاری
  2. تعویضِ پایۀ انشعاب کاری به یک انشعابِ دیگر
  3. توقف یک فرآیند تعویضِ پایه
  4. ازسرگیریِ تعویضِ پایه، پس از رفع تداخل‌ها
  5. استفاده از ابزارِ ادغامِ ثالث برای رفع تداخل‌ها
اداغام

بازگردانی

  1. دور ریختن تمام تغییراتِ محلی از پوشۀ کاری
  2. دور ریختن تمام تغییراتِ صورت گرفته در یک فایل
  3. معکوس کردن یک کامیت (با ایجاد یک کامیت جدید ولی با اعمالِ تغییراتِ معکوس)
  4. انتقال نشان‌گر انشعاب کاری بر روی یک کامیت و دور ریختن تمام تغییراتِ صورت گرفتۀ محلی
  5. انتقال نشان‌گر انشعاب کاری بر روی یک کامیت و نگهداری تغییراتِ صورت گرفتۀ محلی در لیستِ پرواز
  6. انتقال نشان‌گر انشعاب کاری بر روی یک کامیت و نگهداری تغییراتِ صورت گرفتۀ محلی
بازگردانی

چند سرانگشتی مفید در استفاده از Git:

تغییرات مرتبط را باهم کامیت کنید. یک کامیت باید بسته‌ای واحد از تغییرات مرتبط باهم باشد. به‌عنوان‌مثال تغییراتِ مربوط به رفع دو باگِ مختلف، باید در دو کامیت مجزا قرار بگیرند. کامیت‌های کوچک، درکِ تغییرات و بازگردانی آن‌ها در مواقع خطر را برای توسعه‌دهندگان آسان می‌کند. با امکاناتی مانند لیستِ پرواز (Staging Area) و نیز قابلیتِ قرار دادن تنها بخشی از تغییراتِ فایل در لیستِ پرواز که در گیت وجود دارد، ایجاد کامیت‌های کوچک و ریزدانه بسیار ساده است.

زودبه‌زود کامیت کنید. کامیت کردنِ زودبه‌زود به کوچک ماندن آن‌ها و درنتیجه کامیت شدن تغییراتِ مرتبط باهم، کمک می‌کند. گذشته از این، کمک می‌کند تا مرتباً کد خود را با دیگران به اشتراک بگذارید و در طول زمان به رفع تداخل‌های کمتری خواهد انجامید. در مقابل، داشتن کامیت‌های درشت و اشتراکِ دیربه‌دیرِ آن‌ها، همه را دچار کابوس‌های تداخل خواهد کرد. قانونی نانوشته در خصوصِ کنترل نسخه وجود دارد که می‌گوید: همیشه کامیتِ دیرتر، مسئول رفع تداخل‌هاست!

نیمه‌تمام‌ها را کامیت نکنید! همیشه باید کدی که کار آن تمام‌شده است را کامیت کنید. البته به این معنی نیست که مجبورید تمام قابلیت موردنظر را تکمیل کنید. اتفاقاً برعکس: پیاده‌سازی قابلیتِ مدنظر را به بخش‌های منطقیِ کوچک تقسیم کرده و زودبه‌زود کامیت کردن را فراموش نکنید. اما فقط به خاطر اینکه قرار است محل کار را ترک کنید و به خانه بروید، کارهای ناتمام را کامیت نکنید! اگر احیاناً در بین کار خواستید انشعاب کاری خود را تمیز کنید از ابزارِ زیبای اِستَش (Stash) استفاده کنید.

کد خود را قبل از کامیت به‌خوبی تست کنید. بر وسوسۀ کامیت کردن کدی که «فکر می‌کنید» کامل شده است، غلبه کنید. به‌طور کامل آن را تست کنید تا از کامل بودن و نداشتن هیچ‌گونه تأثیر مخرب جانبی اطمینان حاصل کنید. شاید وقتی کامیت‌های نیم‌پز را روی مخزنِ محلی خود قرار می‌دهید خیلی عذاب‌آور نباشد اما وقتی قرار باشد آن‌ها را با دیگران به اشتراک بگذارید، کدهای تست‌شده از اهمیت بالایی برخوردار خواهند بود.

متنِ مناسبی برای کامیت خود بنویسید. پیام خود را با یک جملۀ کوتاه (کمتر از ۵۰ کاراکتر) که چکیده‌ای از تغییرات صورت گرفته است آغاز کنید. عنوان و بدنۀ پیام را با یک خط خالی از هم جدا کنید. اگر مایل به درج توضیحات بیشتر هستید، در بدنۀ پیام به سؤالات زیر پاسخ دهید:

  • چه چیزی انگیزۀ شما در ایجاد این تغییرات بوده است؟
  • تفاوتی که در این پیاده‌سازی ایجاد کرده‌اید چیست؟

کنترل نسخه، ابزارِ پشتیبان گیری نیست! قرار داشتنِ نسخه‌ای از فایل‌های پروژه بر روی یک سرویس‌دهندۀ دور، از آثار جانبیِ مفیدِ به‌کارگیری ابزار کنترل نسخه است. ولی از سامانۀ کنترل نسخۀ خود جوری استفاده نکنید که انگار قرار است نیازهای پشتیبان گیری شما را نیز مرتفع کند. وقتی با کنترل نسخه کار می‌کنید توجه کنید که کامیت‌ها منطقی و معنی‌دار باشند. فقط پر کردنِ سَرسَریِ فایل‌ها جایز نیست.

تا دلتان می‌خواهد از انشعاب‌ها استفاده کنید. یکی از مزیت‌های فوق‌العادۀ گیت نسبت به ابزارهای کنترل نسخۀ دیگر، کم‌هزینه بودن انشعاب گیری در آن است. نحوۀ کار انشعاب‌ها در گیت کاملاً با دیگر ابزارها متفاوت است. انشعاب سازی در گیت یکی از قدرتمندترین قابلیت‌های آن محسوب می‌شود و این موضوع ابداً تصادفی نیست: انشعاب سازی سریع، کم‌هزینه و ساده از روز اول یکی از نیازمندی‌های اولیه در هنگام خلق گیت بوده است. انشعاب‌ها از تداخلِ مسیرهای توسعۀ مختلف، جلوگیری می‌کنید. از آن‌ها در مسیرِ توسعه‌ مرتباً استفاده کنید: برای یک قابلیت جدید، رفع باگ‌ها، ایده‌ها، تغییرات زیرساخت و …

روی یک خط‌مشی توافق کنید و به آن پایبند بمانید. گیت در نوعِ خط‌مشی که انتخاب می‌کنید، سخت‌گیر نیست و اجازه می‌دهد از میان بسیاری از خط مشی های موجود، حق انتخاب داشته باشید: انشعاب‌های بلندمدت (Long-running Branches)، انشعاب‌های موضوعی (Topic Branches)، روشِ ادغام و تعویضِ پایه (Merge & Rebase)، گیت-فلو (git-flow) و غیره. انتخابی که می‌کنید به چند مؤلفۀ مهم بستگی دارد: ماهیتِ پروژه، روش‌هایی که برای توسعه و انتقالِ محصول در میان تیم شما جاری است و از همه مهم‌تر سلیقه! هرکدام از روش‌ها را که برگزیدید، مطمئن شوید که تمام افراد به آن پایبند می‌مانند.

راهنما و مستندات! در هر جا که نیاز به کمک داشتید از دستور زیر استفاده کنید.

راهنما

👋

3 پاسخ

  1. خلاصه و مفید.
    ممنون

  2. خیلی عالی بود. ممنون

    اصطلاح طنازی لیست پرواز خیلی جالب بود. دستور commit -a را بدجور میخواستمش و بلد نبودم. حالا با “commit -am “comment مفیدتر و سریعتر.
    لطفا git branches -av را اصلاح کنید به git branch -av

    1. حق با شماست رضا 🙂 اصلاح شد … ممنون

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *