Skip to main content

مدل Git Flow

این سند، استاندارد Git Flow مورد استفاده در پروژه‌های شرکت را تشریح می‌کند. هدف از این ساختار، ایجاد فرآیندی یکپارچه برای توسعه، بازبینی فنی، تضمین کیفیت (QA) و انتشار نسخه‌ها است تا تمامی تیم‌ها از یک الگوی مشترک پیروی کنند.

این مدل بر پایه استفاده از محیط Stage به عنوان مرجع تست و اعتبارسنجی پیش از انتشار در محیط Production طراحی شده است.

اصول کلی​

در این ساختار، هر Branch مسئولیت مشخصی در چرخه توسعه نرم‌افزار دارد.

  • main تنها مرجع نسخه‌های منتشرشده در Production است.
  • develop نماینده آخرین نسخه قابل استقرار در Stage و مبنای توسعه قابلیت‌های جدید محسوب می‌شود.

ارتباط با CI/CD​

فرآیند استقرار (Deployment) به صورت خودکار و بر اساس Branch مقصد انجام می‌شود.

Branchمحیط استقرار
developStage
mainProduction

بنابراین:

  • هر Push یا Merge به develop باعث استقرار خودکار روی Stage خواهد شد.
  • هر Merge به main باعث استقرار خودکار روی Production خواهد شد.

ساختار Branchها​

main​

Branch اصلی پروژه که همواره نماینده نسخه در حال اجرای Production است.

ویژگی‌ها:

  • فقط شامل نسخه‌های منتشرشده است.
  • هر Commit باید معادل یک نسخه قابل انتشار باشد.
  • تنها از طریق Merge Request مربوط به release یا hotfix به‌روزرسانی می‌شود.
  • انجام Commit مستقیم روی این Branch مجاز نیست.

develop​

Branch اصلی توسعه که تمامی تغییرات قبل از انتشار در آن تجمیع می‌شوند.

ویژگی‌ها:

  • مبنای ایجاد تمامی Featureها است.
  • محیط Integration تیم محسوب می‌شود.
  • هر تغییر پس از Merge به صورت خودکار روی Stage مستقر خواهد شد.
  • نسخه موجود روی Stage همواره از این Branch ایجاد می‌شود.

Working Branch​

ساختار نام‌گذاری:

<JIRA-KEY>

نمونه:

ZIRSAKHT-241

ویژگی‌ها:

  • از Branch develop ایجاد می‌شود.
  • تنها برای پیاده‌سازی یک Task یا Issue استفاده می‌شود.
  • مستقیماً به develop Merge می‌شود.
  • پس از Merge، به صورت خودکار روی Stage مستقر خواهد شد.
  • پس از اتمام کار حذف می‌شود.
  • نام Branch باید دقیقاً برابر با Jira Issue Key باشد.

هر Working Branch تنها باید خروجی یک Merge Request داشته باشد.

Release Branch (اختیاری)​

ساختار نام‌گذاری:

release/<version>

نمونه:

release/1.8.0

این Branch برای پروژه‌هایی استفاده می‌شود که قبل از انتشار نهایی، نیاز به مرحله تثبیت (Stabilization) دارند.

ویژگی‌ها:

  • از develop ایجاد می‌شود.
  • صرفاً برای رفع اشکالات نسخه (Bug Fix) استفاده می‌شود.
  • افزودن قابلیت جدید (Feature) در این مرحله مجاز نیست.

پس از آماده شدن نسخه:

  1. در main Merge می‌شود تا نسخه منتشر گردد.
  2. سپس مجدداً در develop Merge می‌شود تا تغییرات همگام‌سازی شوند.

Hotfix Branch​

ساختار نام‌گذاری:

<JIRA-KEY>

نمونه:

HAMYAR-145

برای رفع سریع مشکلات بحرانی در محیط Production استفاده می‌شود.

ویژگی‌ها:

  • مستقیماً از main ایجاد می‌شود.
  • فقط برای رفع خطاهای بحرانی Production استفاده می‌شود.
  • پس از تأیید، مستقیماً در main Merge و منتشر می‌شود.
  • نام Branch باید برابر Jira Issue Key همان مشکل باشد.

پس از انتشار، تغییرات باید در develop نیز Merge شوند تا در نسخه‌های آینده حفظ شوند.

فرآیند توسعه​

توسعه Feature​

مراحل توسعه یک قابلیت جدید به صورت زیر انجام می‌شود:

develop
│
▼
ZIRSAKHT-241
│
▼
Merge Request
│
▼
Technical Review
│
▼
develop
│
▼
Auto Deploy (Stage)
│
▼
QA

پس از Merge شدن Feature در develop، نسخه جدید به صورت خودکار روی Stage مستقر شده و برای بررسی تیم QA در دسترس قرار می‌گیرد.

فرآیند Technical Review و QA​

ترتیب انجام فرآیندها به صورت زیر است:

  1. ایجاد Merge Request
  2. انجام Technical Review و دریافت تأییدیه
  3. Merge در develop
  4. استقرار خودکار روی Stage
  5. انجام تست توسط تیم QA

بنابراین، بررسی فنی همواره قبل از استقرار در محیط Stage انجام می‌شود.

فرآیند انتشار​

انتشار مستقیم​

در پروژه‌هایی که نیاز به Release Branch ندارند:

develop
│
▼
main

انتشار با Release Branch​

در پروژه‌هایی که مرحله تثبیت نسخه دارند:

develop
│
▼
release
│
▼
main

فرآیند Hotfix​

main
│
▼
HAMYAR-145
│
▼
main
│
                     └────────► Production
│
▼
 develop

قوانین

موارد غیرمجاز​

  • Commit مستقیم روی main
  • افزودن Feature جدید در release
  • ایجاد Working Branch از هر Branch غیر از develop
  • ایجاد Hotfix از هر Branch غیر از main

الزامات​

  • تمامی Featureها باید ابتدا روی Stage مورد بررسی قرار گیرند.
  • Merge به main تنها پس از تأیید Technical Review و QA مجاز است.
  • هر Working Branch باید فقط به یک Jira Issue اختصاص داشته باشد.
  • تمامی تغییرات Production باید در نهایت در develop نیز همگام‌سازی شوند.

جمع‌بندی

رعایت این Git Flow باعث ایجاد فرآیندی استاندارد، قابل پیش‌بینی و کنترل‌شده برای توسعه و انتشار نرم‌افزار خواهد شد.

اجرای صحیح این مدل مستلزم فراهم بودن شرایط زیر است:

  • استقرار سریع و پایدار روی Stage
  • انجام منظم فرآیند QA
  • انجام Technical Review پیش از Merge
  • کنترل کامل فرآیند انتشار در Branch main

در صورت عدم رعایت این فرآیندها، احتمال انتشار تغییرات تأییدنشده و بروز خطا در محیط Production به شکل قابل توجهی افزایش خواهد یافت.