Migrate Branch Protection to Rulesets on GitHub
GitHub can now convert every branch protection rule in a repository to rulesets at once. Here is the click path, what to check, and when to keep old rules.
You can now convert all of a repository's branch protection rules to rulesets in one action. GitHub announced it on 20 October 2026: repository admins go to Settings, then Rulesets, and choose Import branch protection rules. The changelog entry says this extends the earlier option to convert one rule at a time.
This guide walks the migration in an order that cannot leave your main branch unprotected, with extra attention to the rules you set up to keep an AI coding agent from pushing straight to production.
Why bother moving at all
Per the changelog, rulesets offer things branch protection does not:
Pattern-based rules that apply across multiple branches.
Several rulesets stacked for granular policy control.
Management at the organization or enterprise level.
Fine-grained bypass permissions for users, teams, and apps.
If you have one repository and one rule on main, none of that is urgent. If you run several repositories, or you let agents open pull requests on a schedule, a ruleset with a clear bypass list is easier to reason about than a pile of per-branch rules.
The migration, step by step
Write down what you have now. Open the existing branch protection rules and note, for each one, whether it requires pull requests, required reviews, status checks, or blocks force pushes. This is your checklist for step 5.
Open the import. In the repository go to Settings, then Rulesets, then Import branch protection rules.
Read the Review import dialog. According to GitHub it lets you preview the rulesets that will be created, see which rules already have an equivalent ruleset, and review cases where one branch protection rule becomes several rulesets to keep its original behavior.
Choose Evaluate, not Active. The dialog lets you pick an enforcement status of Active, Evaluate, or Disabled. Evaluate is the safe first pass: choosing it lets you see how the new rulesets behave before they enforce anything. Pick which rulesets to create and confirm.
Compare against your checklist. Check each new ruleset against the notes from step 1. Pay particular attention to the split cases from step 3, where one old rule became several rulesets.
Switch to Active. Once the Evaluate results match what you expect, change the enforcement status to Active.
Decide about the old rules. GitHub says the keep-or-delete choice comes after you confirm creation. Keep the original branch protection rules until you have seen the rulesets block something correctly, then delete them.
Step 7 is where people get hurt. Deleting the originals first and discovering a gap second leaves a window with less protection than before.
The protections an AI agent depends on
If an agent has write access to the repository, three behaviors matter more than the rest. Confirm each one survives the migration:
Protection | Why it matters with agents | Where to check |
|---|---|---|
Pull request required before merging to | Stops direct commits to the default branch | The ruleset targeting |
Force pushes blocked | Prevents history rewrites that hide what an agent did | The same ruleset |
Bypass list kept short | Agents using a broad token should not be on it | The ruleset's bypass permissions |
Our guides on setting up branch protection for an AI coding agent and stopping an AI coding agent from committing to main explain why each of those matters. If you are deciding whether an agent should ever merge its own work, read whether to let AI agents merge their own pull requests before you set the bypass list.
What the changelog does not say
GitHub's entry says the feature is "available for all repositories where rulesets are available" and does not name plan tiers. If the import option is missing in your repository, check GitHub's documentation on converting branch protections to repository rulesets for your plan. The entry also gives no timeline for anything further, so do not plan around features it does not mention.
For wider context on the tools involved, the AI coding tools guide is the hub for this cluster.
Frequently asked questions
How do I convert branch protection rules to rulesets?
In the repository, go to Settings, then Rulesets, and select Import branch protection rules. Review the preview, choose an enforcement status, pick the rulesets to create, and confirm. GitHub describes this as converting all rules in a single action.
Should I use Active or Evaluate when importing?
Start with Evaluate. It is one of the three enforcement statuses GitHub offers in the dialog, alongside Active and Disabled, and it lets you check behavior before the rulesets enforce anything.
Will importing delete my existing branch protection rules?
No. GitHub says you decide whether to keep or delete the original rules after the rulesets are created. Keep them until you have confirmed the rulesets work.
Why would one rule become several rulesets?
The Review import dialog flags cases where a single branch protection rule becomes multiple rulesets so that the original behavior is preserved. Check those cases by hand.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
