Home / Knowledge hub / Branch protection
Knowledge hub
Branch protection
Repository rules that stop unreviewed code reaching the main branch.
What it means
Branch protection is a set of rules on a code repository that controls what can happen to an important branch, usually the main one that becomes your release. On GitHub, GitLab and similar platforms you switch the rules on in the repository settings.
Typical rules include requiring a pull request before merging, requiring a number of approvals, requiring automated checks to pass, blocking force pushes and blocking deletion of the branch. Together they ensure nothing reaches release without passing the gate. These rules are enforced by the platform, not by agreement.
Why it matters
Without the rules, anyone with write access can push straight to the main branch, with no review and no test run. One stolen developer token, or one rushed fix at midnight, can put unreviewed code into production. Nobody else sees the change until it is already live.
The rules also give auditors and customers something concrete. They can see that every change to production code was reviewed by a second person and tested. That supports separation of duties, and it lowers the chance of a malicious or accidental change slipping through.
How it shows up
Set the rule for the branches that deploy. Require review, require your build and security checks to pass, and stop old approvals counting after new commits. Pair it with code owners for sensitive paths. A failing check then blocks a merge, as in a security gate.
The mistakes repeat. Administrators are exempt, so the people with most access skip the rules. Checks are optional, so a red build still merges. The rule covers main but not the release branches. Or a bot token can bypass everything. Review the exceptions list, and test the rule by trying to break it.
Questions people ask
Branch protection, answered
Does branch protection stop a compromised admin account?
Not if admins can bypass the rules. Apply the rules to administrators as well, or limit who can bypass, and watch changes to the settings themselves. Otherwise the control is only as strong as that one account.
Is branch protection the same as a security gate?
It is one place to build a gate. Branch protection enforces rules on a branch. A security gate is the idea of blocking a release unless checks pass. The two work together.
Do we still need code review if tests pass?
Yes. Tests check what someone thought to test. A reviewer can notice intent, risk and logic that tests do not cover. Tests and reviewers catch different things, so keep both.
What is the difference between branch protection and rulesets?
Rulesets are a newer GitHub feature that can apply rules across several branches or repositories, with more control. Both aim at the same outcome. Pick whichever your platform recommends. Your repository host will say which it favours.
Should every branch be protected?
No. Protect the ones that deploy or that others build on. Short-lived feature branches can stay open so developers can work freely. Too many rules on throwaway branches just trains people to bypass them.
Sources
Where this comes from
Related
Terms that sit next to this one
Code owners
People named as required reviewers for sensitive parts of a codebase.
Security gate
A pipeline check that must pass before a build is allowed to move on.
Pull request security check
Automatic security testing that runs on a code change before it is merged.
Separation of duties
Splitting a sensitive task so no single person can complete it alone.
Gating a build
Stopping a release automatically when a security check fails.
What reaches production unchecked?
Branch rules decide what gets merged. We can run on a schedule or in CI/CD and gate a build on a proven finding, so a confirmed flaw stops the release. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.