استراتژی شاخه یعنی تیم توافق کند کد از کجا شروع شود، چطور به main برسد، و چه شاخه‌ای حق زنده ماندن طولانی دارد. شاخهٔ چند‌هفته‌ای با main واگرا می‌شود و merge را سخت می‌کند.
🎯 اهداف یادگیری
- GitHub Flow را پیاده کنی
- بدانی Git Flow کجا هنوز معنی دارد
- Trunk-based و feature flag را توضیح دهی
- سیاست شاخه را با Ruleset قفل کنی
شکل ۱۵ — شاخهٔ کوتاه از main، PR، CI، Review، Merge، Deploy.
🌊 GitHub Flow — پیش‌فرض این کتاب
mainهمیشه قابل استقرار است- شاخهٔ کوتاه‌عمر از
main - PR + Checks اجباری
- Merge → deploy خودکار
- اگر خراب شد: revert سریع نه freeze طولانی
مناسب وب، SaaS، اپ‌هایی با feature flag.
🌳 Git Flow — نسخه‌های سنگین
شاخه‌های develop، release/*، hotfix/*، main. برای نرم‌افزار با نسخهٔ شماره‌دار و چرخهٔ QA طولانی (امبدد، موبایل استور با ریویو یک‌هفته‌ای) هنوز زنده است. برای استارتاپ وب سربار است.
🚂 Trunk-Based
همه به main (trunk) با شاخه‌های چندساعته یا مستقیم. فیچر ناتمام پشت feature flag. نیاز به تست عالی و deploy ممتد دارد. گوگل و بسیاری از تیم‌های بزرگ این‌گونه‌اند.
| مدل | طول شاخه | پیچیدگی | سرعت تحویل |
|---|---|---|---|
| GitHub Flow | روز | کم | بالا |
| Git Flow | هفته | زیاد | متوسط |
| Trunk | ساعت | کم در Git، زیاد در flag | خیلی بالا |
هر روز rebase سخت‌تر می‌شود. اگر کار بزرگ است، آن را پشت flag به main تکه‌تکه تحویل بده.
در VS Code git.branchProtection: ["main"] جلوی کامیت مستقیم را می‌گیرد — لایهٔ محلی قبل از Ruleset سرور.
Mid — چرا Git Flow با GitHub Actions درد دارد؟ چون دو شاخهٔ بلند باید همیشه همگام شوند؛ CI دوگانه و cherry-pick hotfix.
Senior — environment protection چگونه با Flow جور می‌شود؟ main → staging خودکار؛ production نیاز به Approve در Environment دارد نه شاخهٔ جداگانهٔ اجباری.
✅ چک‌لیست فهم
- مدل تیم را در یک جمله می‌گویی
- main را مقدس می‌دانی
- شاخهٔ طولانی را بو می‌کشی
فصل بعد: Conventional Commits — زبانی برای ماشین و انسان.