Git Branches

Any organisation — from a two-person startup to a global charity — benefits from branch protection rules in GitHub. They’re included for free on public repositories (and widely available on paid tiers for private repos). GitLab and Bitbucket offer similar features, but GitHub is the most popular platform, so that’s our focus.

You can configure protections in two ways:

⚙️
Branch Settings

Simple rules per branch — quick to set up, good for small teams.

🏢
Rulesets

Reusable policies across multiple repos — ideal for organisations with dozens or hundreds of projects.

Rulesets are the modern way forward. They scale better, layer more consistently, and support audits across teams.

What Is a Branch, and Why Protect It?

A branch in Git is just a line of development. Your main or production branch usually represents code that’s ready for deployment. By default, anyone with write access could push directly to it, delete it, or rewrite history — which is risky.

Branch protection puts controls in place to:

Prevent mistakes — accidental deletion, force pushes
Enforce code quality — reviews, tests, signed commits
Reduce insider risk — scope who can push
Increase resilience — linear history, merge queues

The 10 Rules of Branch Protection

Here’s what GitHub offers and what each setting protects you from — with trade-offs explained.

01

Require Pull Request Before Merging

Benefit No direct pushes to protected branches. Forces code review and CI.
Risk if off Anyone can bypass review entirely.
Trade-off Small teams may find it heavy if everything requires a PR.
02

Require Approvals

Benefit At least one peer must approve before merge.
Risk if off One developer can push insecure code straight through.
Trade-off Don't set "2 approvals" if you only have 2 devs.
03

Require Status Checks

Benefit CI tests must pass before merging. Blocks broken builds.
Risk if off Failing tests can still be merged.
Trade-off Slows velocity if pipelines are flaky.
04

Require Branch Up-to-Date

Benefit Ensures merges are tested against the latest main.
Risk if off Old branch merges can reintroduce bugs.
Trade-off Can cause bottlenecks if main changes frequently.
05

Require Conversation Resolution

Benefit Every comment must be resolved before merge.
Risk if off Feedback can be ignored.
Trade-off Can slow urgent fixes if comments linger.
06

Require Signed Commits

Benefit Cryptographic proof of commit authorship.
Risk if off Attackers could push commits pretending to be others.
Trade-off Devs must configure GPG or SSH signing.
07

Require Linear History

Benefit Prevents messy merge commits. Makes rollbacks cleaner.
Risk if off History rewrites can hide malicious changes.
Trade-off Developers must squash or rebase.
08

Require Deployments Before Merge

Benefit Code must be successfully deployed to staging before merging.
Risk if off Unproven code can hit production.
Trade-off Adds latency to the merge process.
09

Lock Branch

Benefit Makes a branch read-only. Strongest protection for main or release tags.
Risk if off Force pushes or mistakes can break prod history.
Trade-off Must create PRs for even the smallest change.
10

Do Not Allow Bypass

Benefit Even admins must follow the rules. Prevents insider abuse.
Risk if off Admins can silently override protections.
Trade-off Can block emergency hotfixes if not well-planned.

Practical Advice by Team Size

Small Teams
  • PR required
  • One approval
  • CI status checks
Growing Orgs
  • Signed commits
  • Conversation resolution
  • Restrict direct pushes
Large Orgs
  • Org-level rulesets
  • CODEOWNERS reviews
  • Merge queues for velocity
Example: In a two-person project, 2 mandatory reviewers makes no sense — use 1 approval. In an enterprise, enforce multiple approvals with CODEOWNERS to guarantee subject matter review.

Conclusion

Branch protection is not just about Git hygiene — it’s an AppSec control. It prevents unreviewed, untested, or unauthorised changes from ever reaching production. The inconvenience is minimal compared to the protection it provides.

Every organisation should adopt it — whether via branch-level rules or scalable rulesets.

Want to design a branch protection policy that fits your org?

We help teams of all sizes build secure, practical CI/CD workflows.

Get in touch →

References