Git Flow: چیست، مدل شاخه‌بندی و استفاده در پروژه‌ها

Git Flow چیست؟

Git Flow — مدل شاخه‌بندی Git است که ساختار دقیقی از شاخه‌ها و قوانین ادغام برای مدیریت توسعه، انتشارات و رفع‌ها تعیین می‌کند. Vincent Driessen مقاله «یک مدل شاخه‌بندی موفق Git» را در ژانویه ۲۰۱۰ منتشر کرد و از آن زمان Git Flow به استاندارد دوفاکتو در توسعه شرکتی Java و .NET تبدیل شد. ایده اصلی — تقسیم کد به پنج نوع شاخه با سطوح مختلف پایداری است.

به گفته Atlassian Git Tutorials، ۲۰۲۴، Git Flow بر دو شاخه دائمی استوار است: main (قبلاً master) و develop. سایر شاخه‌ها موقتی هستند: feature، release، hotfix. هر نوع شاخه چرخه حیات و قوانین ادغام دقیقی دارد. در توسعه موبایل، Git Flow در پروژه‌هایی با چرخه‌های انتشار منظم (۲–۴ هفته) و پشتیبانی از چندین نسخه استفاده می‌شود.

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

Vincent Driessen و تاریخچه Git Flow

در سال ۲۰۱۰، Vincent Driessen پست «یک مدل شاخه‌بندی موفق Git» را منتشر کرد که به یکی از پراستنادترین مطالب در تاریخ Git تبدیل شد. این مدل برای پروژه‌ای با انتشارات ثابت و پشتیبانی همزمان نسخه‌ها ایجاد شد. در سال ۲۰۲۰، Driessen اعتراف کرد که Git Flow برای شیوه‌های مدرن CI/CD قدیمی شده است، اما مدل همچنان برای پروژه‌هایی با چرخه انتشار طولانی و نیاز به پشتیبانی از نسخه‌های قدیمی مرتبط باقی می‌ماند.

# راه‌اندازی Git Flow
git flow init

# ایجاد شاخه feature
git flow feature start "add-auth"

# تکمیل شاخه feature (ادغام در develop)
git flow feature finish "add-auth"

# ایجاد release
git flow release start "1.2.0"
git flow release finish "1.2.0"

شاخه Main: کد انتشار و برچسب‌گذاری

Main (قبلاً master) — شاخه اصلی که فقط شامل کد انتشار آماده برای استقرار است. هر commit در main باید مربوط به نسخه مشخصی از محصول باشد که با برچسب (tag) در قالب نسخه‌گذاری معنایی مشخص شده است، مانند v1.0.0، v1.1.0. هیچ توسعه مستقیمی در main انجام نمی‌شود — تغییرات فقط از طریق شاخه‌های release یا hotfix وارد اینجا می‌شوند.

به گفته semver.org، ۲۰۲۴، برچسب‌ها در main از قالب MAJOR.MINOR.PATCH استفاده می‌کنند. MAJOR برای تغییرات ناسازگار API، MINOR برای افزودن قابلیت با سازگاری عقب‌گرد، PATCH برای رفع باگ‌ها افزایش می‌یابد. در Git Flow، هر finish release به طور خودکار یک commit در main با برچسب نسخه ایجاد می‌کند.

Main — تنها شاخه‌ای است که در محیط تولید مستقر می‌شود. برای پروژه‌های موبایل، این بدان معناست که با push به main، pipeline ساخت App Bundle یا IPA و انتشار در Google Play / App Store راه‌اندازی می‌شود. در تنظیمات CI/CD GitLab، main در برابر force-push و حذف محافظت می‌شود.

نسخه‌گذاری معنایی و برچسب‌ها

هر commit در main با برچسب در قالب SemVer همراه است: vMAJOR.MINOR.PATCH. MAJOR — برای تغییرات ناسازگار API، MINOR — برای قابلیت جدید با سازگاری عقب‌گرد، PATCH — برای رفع باگ‌ها. مثال: v2.1.0 به معنای دومین انتشار اصلی با ویژگی‌های جدید و بدون رفع باگ است. در Git Flow، برچسب‌ها به طور خودکار هنگام finish release یا hotfix از طریق دستور git flow release finish ایجاد می‌شوند.

شاخه Develop: خط یکپارچه‌سازی توسعه

Develop — دومین شاخه دائمی Git Flow که برای یکپارچه‌سازی تمام ویژگی‌های تکمیل شده طراحی شده است. توسعه‌دهندگان پس از گذراندن بازبینی کد و بررسی‌های CI/CD، شاخه‌های feature را در develop ادغام می‌کنند. Develop آخرین نسخه پایدار کد را شامل تمام ویژگی‌های پیاده‌سازی شده اسپرینت جاری نگه می‌دارد.

به گفته DataSift Git Flow Guide، ۲۰۲۴، develop ممکن است به دلیل یکپارچه‌سازی‌های ناتمام موقتاً ناپایدار باشد. برای جلوگیری از مشکلات، تیم‌ها Continuous Integration (CI) را تمرین می‌کنند: هر ویژگی قبل از ادغام در develop مجموعه کاملی از آزمایش‌ها را پشت سر می‌گذارد. اگر CI ناموفق باشد — توسعه‌دهنده تا ادغام بعدی کد را رفع می‌کند. Develop همیشه به نسخه جاری main متصل است: بلافاصله پس از انتشار، develop از طریق ادغام با main همگام‌سازی می‌شود.

شاخه‌های Feature: توسعه قابلیت‌های جدید

شاخه‌های feature — شاخه‌های موقتی برای توسعه ویژگی‌های جداگانه، رفع باگ‌ها یا آزمایش‌ها. هر شاخه feature از develop ایجاد می‌شود و پس از تکمیل به develop بازمی‌گردد. نام شاخه feature معمولاً شامل شماره وظیفه یا توضیح کوتاه است: feature/APP-123-add-oauth، feature/redesign-profile. در Git Flow، شاخه‌های feature می‌توانند برای مدت نامحدود وجود داشته باشند.

به گفته Pro Git Book، ۲۰۲۴، شاخه‌های feature یک محیط توسعه ایزوله هستند: تغییرات در یک شاخه تا لحظه ادغام بر دیگران تأثیر نمی‌گذارند. در پروژه‌های موبایل، شاخه‌های feature از طریق rebase یا merge با develop همگام‌سازی می‌شوند تا از بروز تضادهای بزرگ در finish جلوگیری شود. توصیه می‌شود قبل از ایجاد MR، شاخه feature را روی develop rebase کنید.

# ایجاد دستی شاخه feature (بدون git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# ایجاد MR در GitLab از طریق CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

شاخه‌های Release: آماده‌سازی انتشار

شاخه‌های release — شاخه‌های موقتی که از develop برای آماده‌سازی انتشار ایجاد می‌شوند. وقتی develop مجموعه کافی از ویژگی‌ها برای نسخه جدید را شامل شود، تیم شاخه release/X.Y.Z (مثلاً release/2.1.0) را ایجاد می‌کند. در این شاخه فقط تغییرات نهایی اعمال می‌شود: افزایش نسخه، به‌روزرسانی بومی‌سازی، آزمایش نهایی، رفع باگ‌های بحرانی.

به گفته Atlassian Git Tutorials، ۲۰۲۴، شاخه release یک مشکل کلیدی را حل می‌کند: ایزوله‌سازی تغییرات نهایی از توسعه موازی. در حالی که release برای انتشار آماده می‌شود، در develop ویژگی‌های جدید برای انتشار بعدی ادغام می‌شوند. پس از تکمیل، شاخه release در main (با برچسب) و در develop (برای همگام‌سازی افزایش نسخه) ادغام می‌شود.

شاخه‌های Hotfix: رفع‌های فوری در تولید

شاخه‌های hotfix — شاخه‌های موقتی برای رفع فوری باگ‌های بحرانی در محیط تولید. تنها نوع شاخه Git Flow که از main ایجاد می‌شود، نه از develop. قالب نام: hotfix/X.Y.Z+1 (مثلاً hotfix/2.1.1). پس از تکمیل، شاخه hotfix به طور همزمان در main (به عنوان انتشار وصله جدید) و در develop (برای اینکه رفع در انتشارات بعدی گم نشود) ادغام می‌شود.

به گفته DataSift Git Flow Guide، ۲۰۲۴، شاخه‌های hotfix باید حداکثر کوتاه باشند — فقط رفع و آزمایش. Hotfix نباید شامل ویژگی‌های جدید یا بازسازی باشد. در توسعه موبایل، hotfix برای رفع خرابی‌های بحرانی (نرخ crash > ۰.۱٪)، آسیب‌پذیری‌های امنیتی یا باگ‌های مسدودکننده در App Store استفاده می‌شود.

مزایا و معایب Git Flow برای توسعه موبایل

Git Flow ساختار واضحی ارائه می‌دهد که به ویژه برای تیم‌های بزرگ و پروژه‌های با انتشارات منظم مفید است. مزایا: ایزوله‌سازی ویژگی‌های ناتمام در شاخه‌های feature، امکان آماده‌سازی انتشار بدون مسدود کردن توسعه، پشتیبانی از چندین نسخه از طریق hotfix. معایب: پیچیدگی برای مبتدیان، نیاز به rebase منظم شاخه‌های feature، تضادها در شاخه‌های طولانی‌عمر.

به گفته Martin Fowler، ۲۰۲۴، اصلی‌ترین عیب Git Flow — شاخه‌های طولانی‌عمر feature هستند. اگر ویژگی ۲+ هفته بدون همگام‌سازی با develop توسعه یابد، تضاد در هنگام ادغام قابل‌توجه می‌شود. برای پروژه‌های موبایل توصیه می‌شود شاخه feature را روزانه از طریق rebase روی develop همگام‌سازی کنید.

Git Flow برای پروژه‌های با Continuous Deployment (هر commit در main → تولید) توصیه نمی‌شود. برای چنین پروژه‌هایی، GitHub Flow یا Trunk-Based Development مدل ساده‌تر و سریع‌تری ارائه می‌دهند. اما برای پروژه‌های با چرخه‌های انتشار و پشتیبانی از نسخه‌های قدیمی، Git Flow همچنان انتخاب بهینه باقی می‌ماند.

چه زمانی Git Flow برای تیم مضر است

Git Flow در سه مورد به مشکل تبدیل می‌شود: تیم کمتر از ۵ نفر (پیچیدگی بیش از حد)، Continuous Deployment (تأخیر در تحویل)، عدم انضباط rebase (شاخه‌های طولانی‌عمر feature تضادهای ادغام ایجاد می‌کنند). اگر تیم بیش از ۲۰٪ زمان را صرف ادغام شاخه‌ها و حل تضادها کند — Git Flow حتی برای تیم بزرگ نیز مناسب نیست.

جایگزین‌های Git Flow: GitHub Flow و Trunk-Based Development

جایگزین‌های Git Flow فرآیند ساده‌تری برای تیم‌های تمرین‌کننده CI/CD ارائه می‌دهند. GitHub Flow فقط از یک شاخه دائمی (main) و شاخه‌های feature استفاده می‌کند. هر ویژگی از main ایجاد می‌شود، پس از بازبینی و CI به main بازمی‌گردد و بلافاصله مستقر می‌شود. GitHub Flow ساده‌تر است، اما از ایزوله‌سازی ویژگی‌های ناتمام و آماده‌سازی موازی انتشار پشتیبانی نمی‌کند.

به گفته GitHub Docs، ۲۰۲۴، Trunk-Based Development (TBD) حتی فراتر می‌رود: همه توسعه‌دهندگان در یک شاخه (trunk) کار می‌کنند و از شاخه‌های کوتاه‌عمر feature به مدت ۱–۲ روز استفاده می‌کنند. Feature toggles (پرچم‌های ویژگی) دید کد ناتمام را کنترل می‌کنند. TBD نیازمند انضباط بالای CI/CD و خودکارسازی آزمایش است.

• GitHub Flow — یک main + شاخه‌های feature، ایده‌آل برای CI/CD و تیم‌های کوچک
• GitLab Flow — Git Flow را با شاخه‌های محیطی (staging, production) توسعه می‌دهد
• Trunk-Based Development — یک شاخه + feature toggles، حداکثر CI/CD، حداقل ادغام
• One Flow — Git Flow ساده‌شده بدون شاخه develop، فقط main + feature + release