Branch protection: شاخهٔ اصلی را از push مستقیم حفظ کنید
قانون حفاظت شاخه برای الزام PR، review، status check و ممنوعیت force push بر اساس مستندات رسمی GitHub.
بنیانگذار و مهندس محصول
اگر همه بتوانند مستقیم روی main پوش کنند، code review و CI اختیاری میشوند. Branch protection rule روی GitHub قید میگذارد: آیا PR لازم است؟ چند تأیید؟ کدام وضعیتهای CI باید سبز باشند؟ آیا force push و حذف شاخه مجاز است؟ مستندات رسمی میگوید با این قواعد میتوانید گردش کار را قبل از تغییر شاخههای مهم اجباری کنید.
این مقاله حداقل پیکربندی معقول برای تیم کوچک تا متوسط را از روی قابلیتهای مستندشده میچیند.
پاسخ کوتاه
برای main یا شاخهٔ پیشفرض: force push و حذف را بسته نگه دارید، Require a pull request before merging را روشن کنید، حداقل یک review بخواهید، و status checkهای CI را required کنید. در صورت امکان مانع bypass همیشگی ادمین شوید تا میانبر فرهنگ را نشکند. الگوهای نام مثل release/* را در صورت نیاز جداگانه محافظت کنید.
حفاظت شاخه جایگزین فرهنگ review نیست؛ آن را قابلاجرا میکند.
پیشفرضهای مهم
طبق Docs، هر قاعدهٔ حفاظت بهصورت پیشفرض force push به شاخههای منطبق را غیرفعال و حذف آنها را ممنوع میکند. میتوانید اختیاری اینها را شل کنید — معمولاً نباید. همچنین بهطور پیشفرض ادمینها میتوانند bypass کنند مگر صریحاً منع شوند.
تنظیمات پرکاربرد
| تنظیم | اثر |
|---|---|
| Require pull request reviews | ادغام فقط پس از تأییدهای لازم |
| Dismiss stale approvals | با تغییر diff، تأیید قبلی باطل میشود |
| Require review from Code Owners | مالک کد در CODEOWNERS باید تأیید کند |
| Require status checks | CI یا وضعیت خارجی باید در حالت مجاز باشد |
| Require branches to be up to date | حالت strict؛ همترازی با پایه |
| Require conversation resolution | نظرات PR باید resolve شوند |
| Require linear history | فقط squash یا rebase merge |
| Require signed commits | فقط commit با امضای تأییدشده |
| Restrict who can push | محدود کردن افراد یا تیم یا اپ |
| Lock branch | فقطخواندنی کردن شاخه |
پیکربندی پیشنهادی شروع
- Settings سپس Branches سپس Add branch protection rule.
- Pattern را main بگذارید.
- Require a pull request before merging و حداقل یک approval.
- Require status checks و انتخاب job پایدار CI.
- در تیمهای منضبط، bypass ادمین را محدود کنید.
- Allow force pushes را خاموش بگذارید.
نام check باید با نام job گردشکار یکی و یکتا باشد؛ Docs دربارهٔ ابهام نام تکراری هشدار میدهد.
Code Owners
text
# .github/CODEOWNERS /app/billing/ @acme/billing-team *.tf @acme/platform
با الزام تأیید مالک، تغییرات حساس بدون چشم متخصص ادغام نمیشوند. مالک باید دسترسی نوشتن داشته باشد تا تأییدیاش معتبر باشد.
Strict در برابر loose برای status checks
در حالت strict شاخه باید قبل از merge با پایه بهروز باشد؛ بیلدهای بیشتر ولی ادغام امنتر. loose کمتر منتظر میماند ولی احتمال شکستن بعد از merge بالاتر است. برای main شلوغ، merge queue در مستندات بهعنوان گزینهٔ مقیاس مطرح شده است.
Rulesets در برابر branch protection کلاسیک
Docs اشاره میکند در یک زمان فقط یک branch protection rule کلاسیک روی یک شاخه اعمال میشود و تشخیص قاعدهٔ برنده سخت میشود؛ rulesets این محدودیت را ندارند و مسیر مهاجرت وجود دارد. اگر سازمان rulesets را استاندارد کرده، همان را دنبال کنید.
استثناها و عملیات اضطراری
گاهی hotfix فوری وسوسهٔ خاموش کردن موقت حفاظت است. بهتر است مسیر اضطراری از پیش تعریف شود: چه کسی bypass مجاز است، چگونه ثبت میشود، و چه زمانی rule برمیگردد. خاموشی بیسند یعنی فردا همهچیز مستقیم به main میرود.
ارتباط با امنیت و تاریخچه
وقتی برای پاکسازی دادهٔ حساس نیاز به force push دارید، حفاظت force push مانع میشود و باید آگاهانه و موقت شل شود — همان نکتهای که Docs در راهنمای حذف دادهٔ حساس میگوید. این استثنا را با runbook امنیتی یکی کنید.
اشتباههای رایج
- Required check با نامی که دیگر در گردشکار نیست؛ همهٔ PRها قفل میشوند.
- اجازهٔ همیشگی bypass ادمین و دور زدن فرهنگ.
- فقط حفاظت main و فراموش شاخههای release.
- الزام review بدون حضور واقعی reviewer.
- روشن کردن signed commits بدون آمادهسازی امضا برای همه.
خلاصه
Branch protection قرارداد اجرایی کیفیت روی شاخههای حیاتی است: PR، review، CI، و بستن force push. حداقل را زود روشن کنید، نام checkها را پایدار نگه دارید، و استثناهای اضطراری را مستند کنید.
سوالات متداول
روی مخزن شخصی Free هم میشود؟
بسیاری قابلیتها در طرحها فرق دارند؛ قبل از وعده به تیم، تنظیمات همان مخزن و Docs طرح را ببینید.
چرا PR تأیید شده ولی merge نمیشود؟
checkها، بهروز نبودن شاخه، گفتوگوی resolveنشده، یا رد شدن توسط reviewer دیگر را بررسی کنید.
آیا protection جلوی commit محلی بد را میگیرد؟
خیر؛ جلوی رسیدن بیضابطه به شاخهٔ محافظتشده روی GitHub را میگیرد.
منابع و مراجع
- GitHub Docs — About protected branches: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
- GitHub Docs — Managing a branch protection rule: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule
- GitHub Docs — About code owners: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
- GitHub Docs — About rulesets: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets
نویسنده
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، میتوانید درباره پروژه صحبت کنیم.
مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ میکنیم.
