Start with required pull requests, required status checks, blocked force pushes and blocked deletion on your main branch, and apply them to admins too. Add signed commits, conversation resolution or a merge queue only if you have a reason. Each rule should fix a specific failure, not just look strict.
What a protected branch can enforce
GitHub's documentation lists the rules a protected branch can apply. The main ones are required pull request reviews (including from code owners), required status checks, required conversation resolution, signed commits, linear history, a merge queue, required deployments, branch locking, push restrictions, and controls over force pushes and deletions. By default GitHub blocks force pushes and deletion on protected branches.
That is a long menu. Here is how to choose.
The core four
Require a pull request before merging. This is the rule that makes every other practice possible. Without it, a single compromised credential can push straight to main.
Require status checks. Tests, linting and your security scans only protect you if a failing result stops the merge. Make the check names required, not just present. Decide whether branches must be up to date before merging. Strict mode is safer but slows busy repositories, which is where a merge queue helps.
Block force pushes. Rewriting history on the branch you ship from destroys the audit trail you will want during an incident.
Block deletion. Cheap, and it prevents a very annoying accident.
Rules that need a reason
Required approvals count. One approval from someone other than the author is a good floor. Raising it to two or three feels safer but often produces larger, batched changes and rubber stamping. DORA's research pages name heavyweight review as a pitfall for small, frequent merges.
Code owners. Valuable for sensitive paths such as authentication, build configuration and deployment files. Keep the owners list short and real, or reviews stall.
Signed commits. They tie a commit to a key. They do not prove the code is safe, and they add friction for contributors. Worth it when you have a threat model that includes spoofed authorship.
Linear history. A tidiness rule more than a security one, although it makes bisecting and reverting simpler.
Dismiss stale approvals and require approval of the most recent push. These stop the swap after approval: someone gets a clean change approved, then pushes something different. Turn these on.
The rule people forget: admins
Rules that do not apply to administrators are suggestions. GitHub lets you extend rules to admins and roles with bypass permission. If you need an emergency path, make it a named, logged process rather than a standing exemption.
A short rollout plan
- Turn on the core four for main and release branches.
- Add dismiss stale approvals.
- Add code owners for the three most sensitive directories.
- Review bypass permissions once a quarter.
Safeguard policies and gates can sit alongside these settings as required checks, so a pull request that introduces a blocked dependency fails before merge. Details are on the Safeguard site, and the free scan is at gold.safeguard.sh/scan.
Quick check
Do branch protection rules stop a compromised maintainer account?
Only partly. If the account can bypass the rules, or approve its own pull requests, they do not help. Apply rules to admins and require an approval from a different person.
Are signed commits required for safe merging?
No. They help attribute commits to keys. They are one control among several and do not replace review or checks.
Sources
Last reviewed: 19 October 2026.
