در این مقاله ما میخواییم پرطرفدارترین flow های رایج گیت رو برای کابران گیت توضیح بدیم تا هرکدام که موردنظر خودتون هست استفاده کنین.
Git Flow
رایج ترین Flow می باشد که در سال 2010 توسط وینسنت ارائه گردید، طبق نظر ایشون ما دو برنچ اصلی داریم که همیشه در مسیر نرم افزار هستند و حذف نمیگردند.
Master : برنچ محصول نهایی در این برنچ قرار میگیرد و نسخه مطمئن و قابل اجرا را ما در هر لحظه در این برنچ داریم.
Develop : برنچی که تمامی توسعه ها از این منشعب شده و به قولی نسخه pre-production در این برنچ موجود می باشد و تمامی feature از این برنچ منشعب و ادغام میشوند
در طول مسیر برنچ های پشتیبانی (supporting branch) ها به شکل زیر می باشند:
feature-* : برنچ هایی که ویژگی های جدید به پروژه ما اضافه خواهند کرد، که از برنچ develop منشعب و دوباره با همین برنچ ادغام میشوند.
hotfix-* : برنچ هایی که برای باگ های حیاتی (critical) ساخته میشوند و همیشه از master منشعب شده و با برنچ های master , develop ادغام میشوند.
release-* : برنچ هایی که برای ایجاد نسخه اجرایی با تعریف نسخه نرم افزاری جدید ساخته میشوند .
مزایا
همیشه و در هر لحظه ساختاری مرتب و تمیزی از ساختار برنچ ها داریم
الگوهای نام گذاری موجود باعث ایجاد برنچ های با معنی میشود
این الگو های در اکثر ابزارهای گیت پشتیبانی می شود
اگر ما نیاز داشته باشیم چند نسخه از محصول داشته باشیم این روش ایده آل است
معایب
تاریخچه گیت در این روش خیلی سخت خواهد بود
برنچ های master / developer بخاطر تکرارهایی که دارد در مباحث CI/DI کار را دشوار میکند
برای محصول هایی که تک نسخه می باشند این روش توصیه نمی شود
GitHub Flow
این Flow به سبک بودن معروف می باشد که در سال 2011 ایجاد شد و داری 6 قانون زیاد می باشد:
هر چیزی در برنچ master قابل استقرار می باشد
همه برنچ ها از master منشعب شده و با نام های توضیفی مشخص میشوند( به فرض می خواهیم پرداخت الکترونیک بانک ملت را اضافه کنیم : mellat-payment)
کامیت های روی سیستم خود را مرتب به بالا(سرور) پوش میکنیم
درخواست pull request رو وقتی میزنیم که برنچ تکمیل شده باشه، نیاز به کمک یا فیدبک داشته باشیم
بعد از اینکه تغییرات بررسی و تایید شد میتونیم با برنچ master ادغام کنیم
بعد از ادغام و بالا فرستادن master میتونید استقرار داشته باشید
مزایا
برای مباحث CI/DI خیلی عالی هستن و بدون مشکلی پیش میره
یک جایگزین ساده برای Git Flow می باشد
برای مواقعی که فقط ی نسخه داریم روش ایده آلی می باشد
معایب
برنج master (کلا کدمون) خیلی پیش میاد که قابل اطمینان نباشه
برای مباحث Release جالب نیست و عملا طرحی برای اون نداره
در رابطه با release,deploy,issue,environment راه حلی ندارد
برای مواقعی که چندین نسخه داریم مناسب نمی باشند
GitLab Flow
این flow توسط GitLab در سال 2014 ایجاد شده است. که بر مبنای feature-driven-development و برنچ های feature با دنبال کردن issue ها می باشد.
بیشترین تفاوت بین GitLab Flow و GitHub Flow در مبحث Environment برنچ هاست که در GitLab Flow وجود دارند(مانند stage , production).
این Flow دارای 11 قانون می باشد :
برنچ های feature مستقیم در master کامیت(ثبت) نمی شوند.
تنها برنچ مستر تست نمی شود و تمامی کامیت ها تست می شود
همه تست ها بعد از هر کامیت اجرا می شوند
قبل از ادغام بررسی کدها انجام می شوند نه بعد از ادغام شدن.
استقرار ها خودکار می باشند مبتنی بر ببرنچ یا tags.
کاربر tag ها را تنظیم میکند نه CI(Continues Delivery)
نسخه ها براساس tag ها می باشد
کامیت هایی که بالا پوش می شوند هرگز rebase نمی شوند
همه از master شروع کرده و به master ختم می شوند
همیشه اول باگ های master حل شده سپس release انجام می شوند
پیام های هر کامیت باید با معنی باشند
مزایا
در این روش نحوه ایجاد CI/DI تعریف شده است
تاریخچه گیت خیلی خوانا می باشد و فاقد بی نظمی می باشد
برای تک نسخه ای ها ایده آل می باشد
معایب
به مراتب خیلی پیچیده تر از GitHub Flow می باشد
در مواقعی که برای نگه داری چندین نسخه در محصول بخواهیم استفاده کنیم پیچیدگی های رو بوجود میاره
One Flow
این مدل روش جایگزینی است که در مقاله GitFlow considered harmful by Adam Ruka در سال 2015 مطرح شد. شرط اصلی که این مدل را راضی نگه میداره اینه همیشه انتشار های جدیدی که در سیستم شروع میشوند بر پایه انتشار های قبلی شروع می شوند. عملا در این مدل ما برنچ Develop رو نداریم و اصلی ترین تفارتش با Git flow می باشد.
مزایا
تاریخچه گیت خیلی خوانا می باشد و فاقد بی نظمی می باشد
منعطف با تصمیمات تیم می باشد
برای تک نسخه ای ها ایده آل می باشد
معایب
برای پروژه هایی که CI/DI دارند اصلا پیشنهاد نمیشود
برنچ های که برای ویژگی های جدید ایجاد میشوند در واقع CI را سخت تر میکند
نتیجه
اینها موارد مطرحی بودند که برای flow های گیت استفاده میشود. هر چند ممکن است تیم هایی با توجه به نیاز خودشون flow اختصاصی خودشون رو ایجاد کرده باشند. اگر از روش های بهتری استفاده کنید شما چه چیزی پیشنهاد میکنین؟
