GitHub Bulk Ruleset Migration: When to Keep Branch Protections
You lowered the required approvals in a new ruleset, yet the pull request still asks for more reviewers. Which rule is the PR actually following during the migration?
- GitHub now converts a repository’s branch protections to rulesets in bulk.
- Keeping the originals means satisfying both them and any active rulesets.
- Review targeting, bypass permissions, and enforcement before removing the old protections.
Bulk conversion works within one repository
GitHub’s October 20 update adds Import branch protection rules under repository Settings → Rulesets. The review dialog previews proposed rulesets and identifies protections already covered by existing rulesets.
Select what to create and its enforcement status, then choose whether to retain or delete the original protections. This is a repository-level conversion, not an automatic migration of every repository in an organization.
One protection can become several rulesets
The conversion guide says GitHub may propose several rulesets when one cannot represent the existing protection. Review the names and behavior-change warnings before creating them.
For an operational review, compare branch targeting and bypass access for administrators, teams, and apps. Matching the number of old and new objects is not a useful test of equivalent behavior.
If you also export configuration for reuse or recovery, keep track of bypass access separately. The management guide says JSON exported from ruleset history excludes the bypass list. That is an export limitation, not a claim that bulk conversion always removes bypass permissions.
Retained protections remain in force
According to GitHub’s layering model, applicable rules accumulate. Rulesets have no priority order; overlapping versions of the same requirement use the most restrictive condition.
| Configuration | Result |
|---|---|
| Original retained; new ruleset Active | Both sets of applicable requirements are enforced. |
| Original retained; new ruleset Evaluate | The original protects the branch; the new ruleset only evaluates. |
| Original deleted; new ruleset Disabled | Neither of those two configurations provides protection. |
A lower approval requirement in a new ruleset therefore does not override a stricter retained requirement. Separately applicable organization rules also need to be considered.
Evaluate does not block a merge
The Enterprise Cloud documentation describes Evaluate as recording would-be violations in Rule Insights without enforcing the rules. Where available, it can help assess a new policy while existing protections remain. Active enforces immediately; Disabled neither enforces nor evaluates.
Creating or editing rulesets requires repository administration access or the custom edit repository rules permission. Free plans support public repositories; private-repository support includes Pro, Team, and Enterprise Cloud. Do not assume every account exposes the same evaluation options.
Review the proposed policy, choose the available enforcement mode, and verify its behavior. Delete original protections based on the replacement’s operation, not merely because the conversion completed.
Frequently asked questions
Does bulk conversion automatically delete the old rules?
No. The import flow lets you choose whether to keep or delete them.
Does Evaluate prevent a noncompliant merge?
No. It records the evaluation without enforcement. Check the replacement’s status before removing existing protections.