GitHub rulesets have no priority order. Every ruleset that targets a branch applies at once, and where two rules disagree, the most restrictive one wins. They also stack with classic branch protection. A bypass list names the roles, teams or apps allowed to skip a ruleset.
How layering works
GitHub's documentation gives an example worth remembering. A ruleset that requires signed commits and three reviews, combined with a branch protection rule that requires linear history and two reviews, results in signed commits, linear history and three required reviews. Nothing is lost, and the stricter value wins.
This means you can add an organization wide baseline and let teams add stricter rules on top. It also means a forgotten rule can block people in ways that are hard to find. List every ruleset and protection rule that matches a branch before you debug.
The bypass list
A ruleset can allow bypass for users with a role such as repository administrator, for specific teams, and for GitHub Apps. Keep the list short and prefer a named team over a broad role. For push rulesets on forks, only people with bypass permission in the root repository can bypass.
Anyone with read access can view active rulesets, which helps developers understand why a push was refused and helps auditors confirm settings without admin rights.
Targets and rule types
Rulesets cover branches, tags and pushes. Branch and tag targets use name patterns. Push rulesets apply to every push and can restrict file paths, path length, file extensions and file size. They are only for private and internal repositories and cover the whole fork network.
Rulesets can also control commit metadata, including commit messages and author email addresses.
Limits to know
Rulesets are available on Team and Enterprise plans. Each repository can hold up to 75 rulesets, and each organization up to 75 organization wide rulesets. Organization level rulesets that target several repositories need the Enterprise plan.
A tidy way to run them
- Start with one baseline ruleset: pull request required, no force pushes, no deletions.
- Add a second ruleset for release branches and tags only.
- Put the bypass team on a short list and review membership quarterly.
- Export or screenshot the settings for your evidence folder.
Before you migrate from classic branch protection, run both side by side. Because rules from every source combine and the stricter one wins, you can add a ruleset without removing the old rule, watch what changes for developers, and remove the old rule once the behaviour matches. Write down the final combined result in plain words, for example three reviews, signed commits, linear history, and put it in your contributing guide so people know what to expect.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which check blocks the merge.
Quick check
Which ruleset wins if two disagree?
None has priority. The most restrictive version of the rule applies.
Do rulesets replace branch protection?
Not automatically. They layer with it on the same branch, so review both.
Sources
Last reviewed: 19 October 2026.
