Git Flow

Git Flow چیه؟

Git Flow یک مدل استاندارد برای مدیریت شاخه‌ها (branches) در گیت هست که کمک می‌کنه توسعه‌ی پروژه به‌صورت منظم، قابل پیش‌بینی و تمیز انجام بشه.

در واقع Git Flow بهت نمی‌گه "چطور از git استفاده کن"،می‌گه "چطور شاخه‌هات رو سازمان‌دهی کن تا کار تیمی و انتشار راحت بشه".

شاخه‌های اصلی در Git Flow

در Git Flow پنج نوع branch اصلی وجود داره:

1.main (یا master) : شاخه‌ی اصلی و رسمی محصول (Production) که هر نسخه ای که منتشر میشه از این شاخه میاد.

2.develop : شاخه‌ی توسعه (Development line) که همه‌ی ویژگی‌ها بعد از تست به این شاخه merge می‌شن آخرین نسخه‌ی آماده‌ی انتشار اینجاست و از این شاخه نسخه‌ی جدید (release) ساخته می‌شه.

stage : در Git Flow استاندارد شاخه‌ای به اسم stage وجود نداره، اما بعضی تیم‌ها خودشون یه شاخه اضافه می‌کنن به اسم stage یا staging. این کاملاً یه توافق تیمی هست و به پروژه و پروسه‌ی دیپلوی بستگی داره.

"در واقع، شاخه‌ی stage یک واسط بین develop و main است که قبل از انتشار نسخه روی main، تست نهایی روی آن انجام می‌شود و QA و تست‌کننده‌ها روی این شاخه کار می‌کنند."

مزیت شاخه‌ی stage:

• امنیت بیشتر برای production: هیچ feature ناقص مستقیم وارد main نمی‌شه.

• تست متمرکز: همه featureها قبل از انتشار واقعی روی یه شاخه هستن

• آماده‌سازی release: گاهی tag یا version نهایی روی stage زده می‌شه قبل از merge به main

نکته‌ی مهم درباره‌ی این شاخه این است که به صورت رسمی جزو Git Flow نیست، به آن گاهی pre-release branch نیز گفته می‌شود و برای تست‌ها و آماده‌سازی‌های پیش از عملیاتی شدن استفاده می‌شود.

ساختار branch

Main (یا Master): شاخه‌ی رسمی و پایدار محصول، همان نسخه‌ای که روی production منتشر می‌شه.

Develop: شاخه‌ی اصلی توسعه، جایی که همه‌ی فیچرها merge می‌شن تا برای انتشار آماده بشن.

Feature Branch: توسعه‌ی قابلیت یا فیچر جدید به صورت مستقل از develop.

Release Branch: آماده‌سازی نسخه‌ی جدید برای انتشار؛ شامل تست و رفع باگ‌های کوچک.

Hotfix Branch: رفع فوری باگ‌ها در نسخه‌ی منتشرشده روی main.

مدل‌های رایج Git Flow

1. Classic Git Flow

برنچ‌ها:
main, develop, release/*, feature/*, hotfix/*

توضیح:
این مدل ساختار استاندارد و کلاسیک Git Flow است.

• توسعه‌های جدید روی develop انجام می‌شوند.

• برای هر نسخه‌ی آماده انتشار، یک برنچ موقت با نام release/0.0.0.0 ساخته می‌شود تا تست نهایی و رفع باگ‌ها روی آن انجام شود.

• پس از نهایی شدن، تغییرات به main (نسخه‌ی پایدار) و develop (برای ادامه توسعه) مرج می‌شوند.

• نسخه‌ها با tag مشخص می‌شوند، نه با برنچ جداگانه.

• در صورت نیاز به رفع سریع باگ در نسخه‌ی منتشرشده، از برنچ hotfix/* استفاده می‌شود.

🟢 مناسب برای پروژه‌های بزرگ یا تیم‌هایی که چند مرحله‌ی مجزا بین توسعه تا انتشار دارند.

2. Git Stage Flow

برنچ‌ها:
main, develop, stage

توضیح:
در این مدل، به جای ساخت برنچ‌های موقتی برای هر نسخه، یک برنچ دائمی به نام stage وجود دارد.

• توسعه‌های جدید روی develop انجام می‌شوند.

• وقتی نسخه‌ای آماده‌ی تست نهایی است، به stage مرج می‌شود.

• پس از تأیید در محیط استیج، تغییرات از stage به main منتقل می‌شود تا منتشر گردد.

🟡 مناسب برای تیم‌هایی با انتشار سریع (CI/CD) یا پروژه‌هایی که نیاز به استیجینگ دائمی دارند.

3. LTS Git Flow (Long-Term Support)

برنچ‌ها:
main, develop, release/1.x, release/2.x, ...

توضیح:
در این مدل، هر نسخه‌ی اصلی (major version) که هنوز پشتیبانی می‌شود، برنچ مخصوص به خودش را دارد.

• توسعه‌های جدید در develop انجام می‌شوند.

• هر نسخه‌ی پایدار در برنچ مخصوص خودش release/1.x , release/2.x و غیره نگهداری می‌شود.

• باگ‌فیکس‌ها یا آپدیت‌های امنیتی روی همان برنچ نسخه انجام می‌گیرند.

• نسخه‌ها معمولاً با tag هم مشخص می‌شوند.

🔵 مناسب برای پروژه‌های Enterprise یا نرم‌افزارهایی که چند نسخه‌ی فعال به‌طور هم‌زمان دارند (مثل APIهایی که مشتریان مختلف از نسخه‌های متفاوت استفاده می‌کنند).