-->
Git در یک نگاه

Git در یک نگاه

هم‌خوان کنید در:

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

نکته: در کارهای روزانه استفاده از اصطلاحاتِ طناز و بومی برای ابزارهایی مثل گیت، کار را برای همه راحت‌تر می‌کند. یکی از این اصطلاحاتِ بامسما که ما در گروه خود از آن استفاده می‌کنید، ترکیبِ «لیستِ پرواز» بجای واژه‌ی نامأنوس Stage است! 🙂
ایجاد
  • نسخه گیری یا نمونه‌گیری از یک مخزنِ خارجی
  • ایجادِ یک مخزن محلی روی رایانه‌ی شخصی
تغییراتِ محلی
  • نمایش فایل‌های تغییر کرده در پوشه‌ی کاری
  • نمایش تغییراتِ درونِ فایل‌های پوشه‌ی کاری با نسخه‌ی قبلشان
  • نمایش تغییراتِ درون فایل‌های لیستِ پرواز با نسخه‌ی قبلشان
  • افزودن تمام تغییرات جاری به لیستِ پرواز برای کامیت بعدی
  • خارج کردن یک فایل از لیستِ پرواز
  • افزودن بخشی از تغییراتِ یک فایل به لیستِ پرواز برای کامیت بعدی
  • کامیتِ یکجای همه‌ی فایل‌های تغییر کرده (بدون نیاز به لیستِ پرواز)
  • کامیتِ تغییراتِ ثبت‌شده در لیستِ پرواز
  • ایجاد تغییر در محتوای کامیتِ آخر
تاریخچه‌ی کامیت‌ها
  • نمایشِ فهرستی از کامیت‌ها با اولویت تاریخِ ثبت
  • نمایش فهرستِ تغییرات صورت گرفته بر روی یک فایل در طول زمان
  • چه زمانی، چه کسی، چه‌کاری را بر روی یک فایل انجام داده است؟
انشعاب‌ها و برچسب‌ها
  • نمایش فهرستی از انشعاب‌های موجود
  • تعویض انشعاب کاری (HEAD)
  • ایجاد یک انشعاب جدید از روی انشعاب کاری
  • حذف یک انشعاب محلی
  • برچسب‌زنی به کامیت آخر
به‌روزرسانی و انتشار
  • نمایش فهرستی از مخازن خارجی (غیر محلی) ثبت‌شده
  • نمایش اطلاعات مربوط به یک مخزن خارجی ثبت‌شده
  • ثبتِ یک مخزن خارجی
  • دانلود تمام تغییرات از مخزن خارجی (بدون تغییر در انشعاب کاری)
  • دانلود تغییرات از مخزن خارجی و ادغام و یکپارچه‌سازی با انشعاب کاری
  • انتشار تغییرات محلی بر روی مخزن خارجی
  • حذف یک انشعاب از روی مخزن خارجی
  • انتشار برچسب‌های محلی
ادغام و تعویضِ پایه (Rebase)
  • ادغام یک انشعاب موجود بر روی انشعاب کاری
  • تعویضِ پایه‌ی انشعاب کاری به یک انشعابِ دیگر
  • توقف یک فرآیند تعویضِ پایه
  • ازسرگیریِ تعویضِ پایه، پس از رفع تداخل‌ها
  • استفاده از ابزارِ ادغامِ ثالث برای رفع تداخل‌ها
بازگردانی
  • دور ریختن تمام تغییراتِ محلی از پوشه‌ی کاری
  • دور ریختن تمام تغییراتِ صورت گرفته در یک فایل
  • معکوس کردن یک کامیت (با ایجاد یک کامیت جدید ولی با اعمالِ تغییراتِ معکوس)
  • انتقال نشان‌گر انشعاب کاری بر روی یک کامیت و دور ریختن تمام تغییراتِ صورت گرفته‌ی محلی
  • انتقال نشان‌گر انشعاب کاری بر روی یک کامیت و نگهداری تغییراتِ صورت گرفته‌ی محلی در لیستِ پرواز
  • انتقال نشان‌گر انشعاب کاری بر روی یک کامیت و نگهداری تغییراتِ صورت گرفته‌ی محلی

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

تغییراتِ مرتبط را باهم کامیت کنید.

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

زودبه‌زود کامیت کنید.

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

نیمه‌تمام‌ها را کامیت نکنید!

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

کد خود را قبل از کامیت به‌خوبی تست کنید.

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

متنِ مناسبی برای کامیت خود بنویسید.

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

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

کنترل نسخه، ابزارِ پشتیبان گیری نیست!

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

تا دلتان می‌خواهد از انشعاب‌ها استفاده کنید.

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

روی یک خط‌مشی توافق کنید و به آن پایبند بمانید.

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

راهنما و مستندات

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


هم‌خوان کنید در:
سهیل صمدزاده

سهیل صمدزاده

من سهیل صمدزاده؛ مشاور چابک سازی گروه‌های نرم‌افزاری، توسعه‌دهنده، مدیر محصول نرم‌افزاری و وبلاگ نویس هستم. به فنّاوری و تفکرات چابک در توسعه نرم‌افزار علاقه‌مندم و سعی می‌کنم در اینجا خُرده دانش‌هایم را با شما به اشتراک بگذارم.


دیدگاه‌های شما ارزشمند‌اند...

3 دیدگاه‌ها برای "Git در یک نگاه"

خبر بده وقتی
avatar
1024

چینش بر اساس:   جدیدترین‌ها | قدیمی‌ترین‌ها
رضا
میهمان
9 ماه 5 روز پیش

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

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

نوید
میهمان
نوید
9 ماه 28 روز پیش

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

وی‌پی‌دیسکاز

به کانال تلگرام آیلِتـــ بپیوندید!

t_logo

آیلِتـــ هر ماه در صندوق ایمیل شما: