Use rulesets when your plan includes them and you want several rules to layer on the same branch, a way to switch enforcement off without deleting anything, and organization wide coverage. Classic branch protection still works and is fine for a simple single repository setup.
How branch protection works
GitHub's documentation lists the options: required pull request reviews, required status checks, conversation resolution, signed commits, linear history, merge queue, required deployments, branch locking, push restrictions, force push and deletion controls.
Two defaults deserve attention. Force pushes and deletions are blocked by default. And restrictions do not apply to administrators, or to roles with the bypass permission, unless you tick the option that stops bypassing.
Only one branch protection rule applies to a branch at a time. With several patterns matching one branch, it can be unclear which one wins.
What rulesets change
Per the docs, rulesets are named lists of rules for branches and tags. They differ in practical ways:
- Several rulesets can apply to the same branch. Rules aggregate, and where definitions conflict the most restrictive applies.
- You can change enforcement status without deleting the ruleset.
- Anyone with read access can see the active rulesets, which helps contributors understand why a push failed.
- They can also control commit metadata such as messages and author emails.
- Push rulesets can block pushes by file path, extension or size on private and internal repositories.
Rulesets are available on GitHub Team and GitHub Enterprise. Each repository can have up to 75. Organization wide rulesets need GitHub Enterprise.
Bypass lists
Both systems have an escape hatch. In rulesets you name who can bypass, by role, team or app. Keep the list short and review it. A bypass actor that nobody remembers is a quiet hole.
A decision guide
Choose classic branch protection if:
- you have one or two repositories,
- your plan does not include rulesets,
- a single rule per branch is enough.
Choose rulesets if:
- you manage many repositories and want consistent rules,
- you want a baseline rule plus stricter rules for release branches,
- you want to trial a rule before enforcing it, or turn it off without losing it,
- you want to restrict file types or sizes on push.
They also layer with each other, so you can migrate gradually. GitHub links a guide for converting protection rules to rulesets.
A sensible baseline
For the default branch, aim for these controls:
- Require a pull request with at least one approval.
- Require status checks, including your security scan.
- Dismiss stale approvals when new commits arrive.
- Block force pushes and deletions.
- Apply the rules to administrators.
- Require code owner review for sensitive paths. See using CODEOWNERS.
Safeguard policies and gates can act as one of those required checks. The gate pull request demo shows the idea.
Click through it at your own pace, or open it full screen.
Quick check
Do rulesets replace branch protection immediately?
No. They layer with existing protection rules, and the most restrictive version of a duplicated rule applies.
Do branch rules stop repository admins?
Not by default for classic protection. Enable the option that applies restrictions to administrators.
Sources
Last reviewed: 19 October 2026.
