Skip to content
Back to blog
CI/CD

Branch Protection Rules Best Practices

How to configure branch protection to actually enforce code review and prevent force-pushes, and the settings teams commonly get wrong.

S
SecureScout Team· Security Engineering
May 22, 20265 min read

A protected branch that isn't actually enforcing what the team assumes it's enforcing is one of the more common gaps between intended and actual security posture — the settings exist, but a specific checkbox left unchecked quietly undermines them.

Require pull request review before merging

The baseline: no direct pushes to the protected branch, and at least one approving review required before a merge. Without this, the review process is optional in practice, relying entirely on developer discipline rather than being enforced.

Include administrators in the rule

Most platforms let branch protection rules exclude repository administrators by default, allowing them to bypass required reviews. This is frequently left unconfigured, meaning the "required review" isn't actually required for anyone with admin access — worth explicitly checking, not assuming.

Require status checks to pass

Beyond human review, require that CI checks (tests, linting, security scans) pass before a merge is allowed. A pull request with a failing security scan shouldn't be mergeable regardless of human approval, if the scan is meant to be a hard gate.

Restrict force-pushes and deletions

Force-pushing to a protected branch can rewrite history in ways that hide previous commits, and branch deletion can remove work or audit trail entirely. Both should be disabled on protected branches by default.

Require up-to-date branches before merging

Requiring a branch to be up to date with the target branch before merge ensures the CI checks that ran actually reflect the code as it will exist after merging — without this, a check can pass against stale code that no longer matches what's about to be merged.

Use CODEOWNERS for sensitive paths

Rather than requiring generic approval from anyone, CODEOWNERS lets you require approval specifically from designated owners of sensitive areas of the codebase (authentication logic, infrastructure configuration, payment handling) — ensuring the right expertise reviews the highest-risk changes.

Periodically audit the actual configuration

Branch protection settings can drift or be temporarily relaxed for a specific merge and never re-enabled. Periodically reviewing the actual configured rules, not just assuming they match what was originally set up, catches this kind of drift.

branch-protectiongithubcode-review

Frequently Asked Questions

Does branch protection apply to repository administrators by default?

Not by default in many platforms — there's often a separate setting to include administrators in the protection rules, and it's commonly left unchecked, allowing admins to bypass required reviews without anyone noticing.

Is requiring a single approval enough for sensitive repositories?

For repositories touching production infrastructure, payments, or security-critical code, requiring two approvals, or requiring approval specifically from a designated code owner for the affected paths, is a stronger bar than a single generic approval.

Related Articles

S

SecureScout Team

Security Engineering

Learn more →