Branch merging restrictions
Implement branch merging restrictions
Restricting who and what
| Restriction | Effect |
|---|---|
| Require a pull request | No direct pushes to the branch |
| Restrict who can push | Only named people, teams or apps may merge |
| Require status checks to pass | Merge blocked until checks are green |
| Require branches to be up to date | Must rebuild against the latest target first |
| Include administrators | The rules apply to admins too |
The two that get missed
Include administrators. A protection rule that exempts administrators protects the branch from everyone except the people most able to break it in a hurry — usually during an incident, which is exactly when the safeguards matter most. If a break-glass path is genuinely needed, make it explicit and audited rather than an implicit exemption.
Require branches to be up to date. Without it, two pull requests can each pass all checks against an older main and produce a broken main when both merge. Neither change is individually at fault; the combination was never tested. Requiring an up-to-date branch forces revalidation against what is actually there — at the cost of rebuilding when the target moves.
Force pushes and deletion
Blocking force pushes and branch deletion on protected branches prevents history from being rewritten under everyone else. On a shared branch a force push does not merely lose commits — it invalidates every clone that already fetched.
Primary sources