برسی استاندارد های Branching Model در گیت

Git flow 

 به طور خلاصه 
در این استاندارد قابلیت های جدید تحت شاخه های feature در شاخه develop ادغام میشوند. 
در زمان رسیدن به زمان انتشار نسخه (چه از بعد تعداد قابلیت جدید یا زمان ) شاخه release ی از شاخه develop شده و اماده تست uat میشود.
 شاخه master همیشه شامل نسخه لایو میباشد.
 درصورت وجود باگ در نسخه لایو شاخه hotfix ی از master ساخته شده و در نهایت در شاخه master و develop ادغام میشود. 
 
 
مزایا 
 
اطمینان از تمیز بودن هر شاخه در طول عمر هر پروژه به واسطه تفکیک زیاد شاخه ها از هم
نام گذاری قابل فهم شاخه ها
پشتیبانی قوی در ابزارهای git 
مناسب برای زمانی که میخواهیم چندین ورژن از محصول در محیط لایو یا عملیاتی داشته باشیم
 
معایب
 
تاریخچه کامیت های گیت خوانا نمیباشد
جداسازی شاخه master و develop بنوعی اضافه تلقی میشود و باعث سخت شدن پروسه ها ci/cd میشود
برای داشتن تنها یک نسخه در محیط لایو یا عملیات توصیه نمیشود
 

Github flow

 
 ساده ترین استاندارد میباشد و به طور خلاصه در این استاندارد قابلیت های جدید تحت شاخه های feature در شاخه develop ادغام میشوند.
 


مزایا
 
مناسب برای پروسه های ci/cd ساده 
مناسب برای زمانی که تنها یک نسخه در محیط لایو یا عملیات داریم
 
 معایب
 
کد محیط لایو یا عملیاتی به راحتی میتواند خراب شود (بدلیل کم بودن شاخه ها تا رسیدن تغییرات به شاخه اصلی) 
برای زمانی که نیاز به پلن انتشار (release plans)داریم نامناسب و ناکافی میباشد! 
نامناسب برای زمانی که میخواهیم چندین ورژن از محصول در محیط لایو یا عملیاتی داشته باشیم 
 

Gitlab flow 

 
این استاندارد به صورت پیش فرض در gitlab استفاده میشود و به نوعی ترکیب 2 استاندارد قبلی میباشد و علاوه بر مدل github flow (یعنی ساختن feature از master ) 3 مدل دیگر در branching طبق شکل زیر داریم شاخه Production شاخه های محیطی مثلا uat,pre-production,production و... شاخه های انتشاری مثلا 1-1-stable,1-2-stable و ... 
 
 
 
مزایا
 مناسب برای پروسه های ci/cd 
تاریخچه کامیت های گیت خوانا میباشد 
مناسب برای زمانی که تنها یک نسخه در محیط لایو یا عملیات داریم 
 
معایب
 
 سخت تر نسبت به github flow 
به مرور پیچیده شدن در صورت نیاز به نگهداری چندین ورژن در محیط لایو یا عملیاتی 
 
 
نتیجه گیری : 
 
هرکدام از این سه استاندارد مزایا و معایب خود را دارند و باید بسته به نوع پروژه انتخاب شوند و به اصللاح استاندارد one size fits all نداریم.

نظرات

پست‌های معروف از این وبلاگ

مقدمه ای بر RavenDB – قسمت دوم

مقدمه ای بر RavenDB – قسمت سوم

lnav ابزاری بسیار کاربردی برای پیمایش لاگ ها در لینوکس و البته مک