Branch protection is a set of rules on a source code repository that limits how changes can reach an important branch, such as main or a release branch.
Typical rules require a pull request before merging, require one or more approving reviews, require automated checks to pass, and block force pushes or branch deletion. GitHub calls these protected branches and also offers rulesets. GitLab uses the term protected branches. Other code hosts have similar features under different names.
In simple terms, branch protection answers:
- Can anyone push code straight to the branch that deploys to production?
- Does every change get reviewed and tested before it merges?
- Who, if anyone, can bypass those rules?
Why Branch Protection Matters
The default branch of a production repository is often the last gate before code ships. If anyone can push to it directly, review and testing become optional habits instead of enforced steps.
Branch protection matters because:
- It turns a review policy into a rule the system enforces.
- It blocks accidental force pushes that can rewrite or erase history.
- It makes required checks, such as tests and security scans, actually required.
- It supports segregation of duties by requiring approval from someone other than the author.
- Auditors testing change management often ask to see it configured.
Common Branch Protection Settings
The exact names differ by platform. Common settings on GitHub protected branches and rulesets include:
| Setting | What it does |
|---|---|
| Require a pull request before merging | Blocks direct pushes; changes arrive through a reviewed pull request |
| Required approvals | Sets how many approving reviews a pull request needs |
| Dismiss stale approvals | Clears approvals when new commits are pushed after review |
| Require review from code owners | Requires approval from owners of the files changed |
| Require status checks to pass | Blocks merging until selected CI checks succeed |
| Require conversation resolution | Blocks merging while review comments are unresolved |
| Block force pushes | Prevents rewriting the branch history |
| Block deletions | Prevents deleting the protected branch |
| Restrict who can push or bypass | Limits which people or apps can push or skip the rules |
See GitHub's documentation on about protected branches and GitLab's documentation on protected branches for current options.
Branch Protection vs Related Terms
| Term | Primary job | How it relates |
|---|---|---|
| Branch protection | Enforce rules on how code reaches a branch | The technical gate in the repository |
| Change management | Control how changes reach production | The broader process; branch protection is one enforcement point |
| Pull request approval | Record that a reviewer approved a change | The per-change evidence that the protection rule produces |
| Workflow approval | Record approvals in any workflow | The general concept; pull request approval is one example |
| Segregation of duties | Split sensitive steps across people | Branch protection is a common way to enforce author vs approver separation |
Bypass and Admin Access
Most platforms let administrators or specific apps bypass branch protection. That is sometimes necessary for emergencies, but it is also the most common gap.
Teams usually handle bypass by:
- Turning on settings that apply rules to administrators where the platform allows it
- Limiting the bypass list to a small, named group
- Requiring a ticket for any emergency bypass and reviewing it afterward
- Watching the code host's audit log for changes to protection settings
A protection rule that admins skip quietly every week is not much of a control.
Evidence Themes Auditors May Expect
Auditors set their own procedures, but branch protection evidence commonly includes:
- Screenshots or exports of the protection settings for in-scope repositories and branches
- Evidence that settings stayed in place across the audit period, such as audit log entries showing no unapproved changes
- A list of who can bypass the rules
- Samples of merged pull requests showing approvals and passing checks
- Records for any emergency changes that bypassed the normal path
Framework Notes
SOC 2
SOC 2 does not require branch protection by name. The AICPA Trust Services Criteria expect changes to be authorized, tested, approved, and implemented in a controlled way under CC8.1. Branch protection is a common way engineering teams support that criterion. See What Are the Trust Services Criteria?.
NIST and ISO
NIST SP 800-53 Rev. 5 covers configuration change control in CM-3 and access restrictions for change in CM-5. ISO/IEC 27001:2022 Annex A includes controls on access to source code (8.4) and change management (8.32). Neither names branch protection directly; teams map it as an implementation.
Common Failures
- Protection set on
mainbut not on release or deploy branches - Required approvals set to zero
- Administrators exempt from all rules with no review
- Status checks configured but not marked as required
- Stale approvals counted after new code was pushed
- New repositories created without any protection
- No record of when protection settings changed
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For branch protection, that can mean dated history for pull request reviews, merges, and related tickets, so samples are easier to pull for the audit period. GitHub or your code host remains the system of record for protection settings. AuditFlo.co does not configure your repositories, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
Branch protection is the repository rule set that controls how code reaches important branches: pull requests, approvals, required checks, and limits on force pushes and bypass. It turns change management policy into an enforced gate. For audits, show the settings, show they stayed in place, and show sampled changes that went through them.