استراتژی‌های انشعاب Git – انجمن DEV

استراتژی های انشعاب Git تکنیک هایی برای سازماندهی و مدیریت توسعه ویژگی، همکاری و کنترل نسخه در یک پروژه هستند. انتخاب استراتژی مناسب به اندازه تیم، نیازهای پروژه و نیازهای استقرار بستگی دارد. در زیر متداول ترین استراتژی های انشعاب Git آورده شده است:

1. Git Flow

یک استراتژی قوی و محبوب برای پروژه هایی با چرخه های انتشار برنامه ریزی شده.

شاخه ها:

• اصلی (استاد): حاوی کد پایدار و آماده تولید است.
• توسعه دهید: به عنوان شاخه یکپارچه سازی ویژگی ها عمل می کند. این جایی است که نسخه بعدی آماده می شود.
• شاخه های ویژه: ایجاد شده برای ویژگی ها یا وظایف فردی، منشعب شده است develop.
• شعبه ها را آزاد کنید: ایجاد شده برای آماده شدن برای انتشار، منشعب شده است develop.
• شعبه های رفع فوری: برای رفع مشکلات حیاتی در تولید، منشعب شده استفاده می شود main.

جریان:

1. شاخه های ویژگی در ادغام می شوند develop پس از اتمام.
2. چه زمانی develop پایدار است، یک شاخه انتشار ایجاد می شود، آزمایش می شود و در آن ادغام می شود main.
3. رفع بحرانی از طریق شاخه های رفع فوری به طور مستقیم بر روی اعمال می شود main و backport به develop.

موارد استفاده:

• پروژه هایی با انتشار برنامه ریزی شده
• پروژه های پیچیده با توسعه دهندگان متعدد.

2. GitHub Flow

یک مدل انشعاب ساده تر که معمولاً برای استقرار مداوم استفاده می شود.

شاخه ها:

• اصلی: تنها شعبه دائمی که حاوی کد آماده تولید است.
• شاخه های ویژه: ایجاد شده برای ویژگی های فردی یا رفع اشکال، منشعب شده است main.

جریان:

1. روی شاخه ویژگی کار کنید.
2. هنگامی که آماده ادغام هستید، درخواست کشش (PR) را باز کنید main.
3. پس از بررسی کد و بررسی CI/CD، شاخه ویژگی را در آن ادغام کنید main.
4. مستقر مستقیم از main.

موارد استفاده:

• تیم های کوچک.
• پروژه هایی که مستلزم استقرار مکرر هستند.

3. GitLab Flow

یک استراتژی انعطاف پذیر که عناصر Git Flow و GitHub Flow را ترکیب می کند. با خطوط لوله CI/CD به خوبی کار می کند.

شاخه ها:

• اصلی (یا تولید): کد پایدار، آماده تولید.
• شاخه های خاص محیط زیست: شاخه های اختیاری مانند staging یا pre-production.
• شاخه های ویژه: برای ویژگی های جدید یا رفع اشکال، منشعب شده است main.

جریان:

1. توسعه ویژگی ها در شاخه های ویژگی.
2. ادغام تغییرات در شاخه محیط مناسب (به عنوان مثال، staging برای آزمایش).
3. استقرار از شاخه محیط زیست تا تولید.

موارد استفاده:

• تیم هایی با محیط های متعدد (به عنوان مثال، توسعه دهنده، مرحله بندی، تولید).
• پروژه هایی که نیاز به استقرار دستی یا مرحله ای دارند.

4. توسعه مبتنی بر تنه

یک استراتژی مینیمالیستی با تاکید بر سادگی و یکپارچگی سریع.

شاخه ها:

• اصلی (تنه): تنها شاخه با عمر طولانی.
• شاخه های ویژه کوتاه مدت: شاخه های اختیاری برای ویژگی های جدید، که اغلب ظرف چند ساعت یا چند روز ادغام می شوند.

جریان:

1. توسعه دهندگان به طور مستقیم متعهد می شوند main یا از شاخه های کوتاه مدت استفاده کنید.
2. از تست خودکار برای اطمینان از ثبات استفاده کنید.
3. ادغام های مکرر شاخه تنه را به روز نگه می دارد.

موارد استفاده:

• تیم های چابک در حال تمرین یکپارچه سازی مداوم (CI).
• پروژه هایی با چرخه توسعه سریع.

5. جریان را آزاد کنید

یک استراتژی انشعاب مبتنی بر مایکروسافت که برای انتشار نرم افزار در مقیاس بزرگ طراحی شده است.

شاخه ها:

• اصلی: شاخه پایدار برای تولید.
• شاخه های ویژه: برای توسعه ویژگی.
• شعبه ها را آزاد کنید: برای تهیه و تثبیت رهاسازی خاص استفاده می شود.

جریان:

1. روی ویژگی ها در شاخه های ویژگی کار کنید.
2. ادغام ویژگی های تکمیل شده در main.
3. برای آزمایش نهایی، تثبیت و استقرار یک شاخه انتشار ایجاد کنید.

موارد استفاده:

• پروژه های سازمانی با برنامه های دقیق انتشار.

جدول مقایسه استراتژی ها

بهترین روش ها برای انشعاب

1. از نام های شعب توصیفی استفاده کنید: از نام هایی مانند استفاده کنید feature/login، bugfix/header-issue، یا hotfix/payment-fix برای وضوح
2. بررسی کد: همیشه از درخواست های کشش/ادغام برای اطمینان از کیفیت کد و حفظ همکاری استفاده کنید.
3. تست خودکار: خطوط لوله CI/CD را برای آزمایش و اعتبارسنجی خودکار تغییرات قبل از ادغام، یکپارچه کنید.
4. ادغام به طور منظم: شعب را به روز نگه دارید main برای جلوگیری از تضادهای بزرگ و پیچیده ادغام.
5. شاخه های قدیمی را حذف کنید: پس از ادغام شاخه ها را حذف کنید تا مخزن تمیز بماند.

وظیفه: یک استراتژی انشعاب برای پروژه های تیم خود ایجاد کنید.

در اینجا یک پیشنهاد است استراتژی انشعاب برای پروژه های تیم شما، طراحی شده برای ایجاد تعادل بین کارایی، همکاری و ثبات کد. این استراتژی فرض می‌کند که تیم شما در یک محیط Agile کار می‌کند و مرتباً به‌روزرسانی‌ها را ارائه می‌کند.

مروری بر استراتژی انشعاب

ما ترکیبی از GitLab Flow و توسعه مبتنی بر تنه، برای نیازهای تیم طراحی شده است. این رویکرد با خطوط لوله CI/CD و محیط های متعدد (مانند توسعه، مرحله بندی و تولید) به خوبی کار می کند.

شاخه ها

1. main (یا production):

   • همیشه حاوی کد پایدار و آماده تولید است.
   • برای استقرار در تولید استفاده می شود.
   • شاخه محافظت شده: فقط درخواست های کششی (PRs) می توانند در آن ادغام شوند main، نیاز به تأییدیه ها و بررسی های CI.

2. develop (اختیاری در صورت نیاز به یک شاخه یکپارچه سازی اختصاصی):

   • برای ادغام ویژگی های تکمیل شده و آزمایش آنها قبل از رفتن به استفاده می شود main.
   • برای تیم هایی که مرحله مرحله قبل از تولید را ترجیح می دهند.

3. شاخه های ویژه:

   • برای توسعه ویژگی‌های جدید، پیشرفت‌ها یا رفع اشکال ایجاد شده است.
   • قرارداد نامگذاری: feature/ یا bugfix/.
   • ادغام شد main یا develop پس از بررسی و تست کد

4. شعبه های رفع فوری:

   • برای رفع مشکلات حیاتی در تولید استفاده می شود.
   • قرارداد نامگذاری: hotfix/.
   • منشعب شد main و دوباره در هر دو ادغام شد main و develop (یا شاخه های ویژگی مربوطه).

5. شاخه های محیط زیست (اختیاری):

   • برای مدیریت محیط های خاص مانند staging یا qa.
   • staging برای آزمایش تغییرات نهایی قبل از ادغام استفاده می شود main.

جریان کار

توسعه ویژگی

1. توسعه دهنده یک شعبه از main (یا develop در صورت استفاده از a develop شاخه).

   git checkout -b feature/ main

1. برنامه‌نویس روی این ویژگی کار می‌کند، تغییراتی را انجام می‌دهد و به شاخه راه دور فشار می‌آورد.

   git push origin feature/

1. پس از تکمیل، یک درخواست کشش (PR) را باز کنید main یا develop برای بررسی
2. پس از تایید و تست های موفقیت آمیز CI، شاخه ویژگی ادغام می شود.
3. پس از ادغام، شاخه ویژگی را حذف کنید تا مخزن تمیز بماند.

منتشر می کند

1. هنگامی که برای انتشار آماده شدید، یک شاخه انتشار ایجاد کنید (در صورت نیاز):

   git checkout -b release/ develop

1. آزمایش نهایی را روی شاخه انتشار انجام دهید.
2. هر گونه اشکال را مستقیماً در شاخه انتشار برطرف کنید.
3. شاخه انتشار را در ادغام کنید main و نسخه منتشر شده را تگ کنید:

   git tag -a v1.0 -m "Release version 1.0"
   git push origin --tags

1. به صورت اختیاری، شاخه انتشار را دوباره در آن ادغام کنید develop برای به روز نگه داشتن آن

رفع فوری

1. یک شاخه Hotfix ایجاد کنید main:

   git checkout -b hotfix/ main

1. مشکل را برطرف کنید و تغییرات را فشار دهید.
2. شاخه Hotfix را در آن ادغام کنید main و استقرار به تولید:

   git checkout main
   git merge hotfix/
   git push origin main

1. بکپورت رفع مشکل به develop برای اطمینان از ثبات

کنوانسیون های نامگذاری

• feature/: ویژگی ها یا پیشرفت های جدید.
• bugfix/: رفع اشکال غیر بحرانی.
• hotfix/: رفع بحرانی برای مشکلات تولید.
• release/: شاخه های مخصوص انتشار.
• staging، qa، یا dev: شاخه های خاص محیط زیست.

ادغام CI/CD

1. تست خودکار:

   • همه شاخه ها باید آزمایش های خودکار را در خطوط لوله CI/CD راه اندازی کنند.
   • قبل از اجازه دادن به ادغام، از گذراندن تست‌ها اطمینان حاصل کنید main یا develop.

2. بررسی کد:

   • به حداقل یک بازبین برای PR نیاز دارید.
   • از ابزارهای بررسی کد برای حفظ کیفیت و اطمینان از رعایت استانداردهای کدنویسی استفاده کنید.

3. استقرار:

   • استقرار خودکار main پس از گذراندن چک های CI/CD، به تولید تبدیل می شود.
   • مستقر کنید staging به یک محیط مرحله‌بندی برای آزمایش منشعب شوید.

بهترین شیوه ها

1. ادغام های کوچک و مکرر: تغییرات را به طور مکرر ادغام کنید تا از درگیری های بزرگ و پیچیده جلوگیری کنید.
2. اجرای شعبه های حفاظت شده: محافظت کنید main و develop برای اطمینان از عدم تعهد مستقیم
3. شاخه های ادغام شده را حذف کنید: با حذف شاخه های ادغام شده، مخزن را تمیز نگه دارید.
4. از Pull Requests استفاده کنید: همیشه PR برای بررسی و آزمایش کد ایجاد کنید.
5. تغییرات سند: اسناد یا لاگ های تغییرات را به عنوان بخشی از فرآیند انتشار به روز کنید.

مثال گردش کار بصری

main
  |
  |--------- hotfix/
  |
  |--------- release/
  |                 |
develop ------------|
  |       \-------- feature/
  |       \-------- bugfix/
  |

یادگیری مبارک!!!