در سری های قبلی از نقطه نظر تکنیکی کار با git را تا حدودی توضیح دادم (قسمت اول ، قسمت دوم ، قسمت سوم)، اما بعد از یادگرفتن ابزار کاربردها و فرآیند استفاده از ابزار هم مهم هست. یک ویژگی مهم git شاخه زدن یا branching هست، وقتی قصد دارید به صورت همزمان چندین کار رو پیش ببرید از یک نقطه زمانی انشعاب می زنید و زمانی که کارتون تموم شد شاخه رو به شاخه اصلی (معمولا با نام master ) پیوند می زنیم تا در نهایت یک سورس نهایی داشته باشیم. حتما می دونید که به فرآیند پیوند زدن هم merge گفته میشه.  branch و merge امکاناتی بودن که در سیستم های قدیمی تر و در نوع های غیر توزیع شده (مانند subversion) به دلایل مشکلات و سختی هاشون به این شدت استفاده نمی شدند یک سوال خوب درstackoveflow  مورد مقایسه بین merge در سیستم های توزیع شده مثل git با subversion وجود داره که به طور مفصل توضیح داده، قصد ندارم در موردش الان صحبت کنم ، همین قدر بدونید که branching و merge جزهایی از git هستند که شما به راحتی و تعداد زیاد در روز از اون ها استفاده خواهید کرد.

برگردیم به اصل موضوع، عموم ابزارها همیشه شامل اون مثل مشهور"شمشیر دو لبه" می شوند، در عین حال که استفاده از branch برای جدا کردن فرآیند های موازی می تونه مفید باشه اما اگر از یک الگو مناسب برای اینکار استفاده نکنیم نهایتا ممکنه به چیزی شبیه تار و پود قالی برسیم،‌ تعداد زیاد branch ها در زمانی که احتیاج دارید به سابقه کارهاتون دسترسی داشته باشید گیج کننده خواهد بود



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

  • ما تو شرکت همیشه فورس کاری داریم ، همیشه اولویت ها در حال تغییر هستند ، بسیار پیش میاد که در روز ریلیز feature جدید اضافه میشه و زمان بندی ها بهم میخوره واحد تست همزمان کار تست رو انجام میده و ما همزمان به توسعه ادامه میدیم، شما نمی تونید چیزی که کار نمیکنه رو دست واحد تست بدید در عین حال نمی تونید واحد تست رو معطل پیاده سازی تا زمان رسیدن نسخه که کار کنه بکنید، فرضا شما یک feature رو پیاده کردید برای صرفه جویی در وقت به واحد تست میدید و همزمان روی feature دوم کار می کنید. در این حالت وقتی جواب تست میاد چه کار باید کرد ؟! پیاده سازی رو متوقف کنیم و باگ ها رو رفع کنیم سپس پیاده سازی رو ادامه بدید؟ اگر باگ ها مربوط به feature جدید هم میشد آنگاه اولویت با کدومشون بود ؟ به طور کلی سناریوهای متفاوتی می تونه پیش بیاد اما چیزی که مهم هست زمان هست! زمان هزینه است و ما به صورت pipeline کار میکنیم. باید کنترل خوبی رو سورسمون داشته باشیم تا در صورت لزوم نسخه جدیدی برای بسازیم.
  • feature های وجود داره که باید پیاده بشن اما وجودشون در release پیشرو قطعیت نداره
  • یک maintenance کلی برای بهبود پروژه و همچنین cleanup کردن کد برای افزایش طول عمر برنامه همیشه در جریان خواهد بود.
  • گاها پیش میاد که یک باگ خطرناک کشف بشه و لازمه در همه شاخه ها merge بشه
  • خود merge شدن نباید باعث از بین رفتن تاریخچه بشه.

خوندن مقاله رو اکیدا پیشنهاد میکنم، اگر تجربه در این زمینه دارید خیلی دوست دارم من رو هم سهیم کنید :)

[1] : هر چند که خیلی فاصله وجود داره و حتی من معتقدم اسکرام تو همه محیط ها و همه نیاز ها جوابگو نیست که در این باره حتما مفصل تر می نویسم.