Classic branch protection rules and repository rulesets have coexisted awkwardly for a couple of years: two systems doing the same job, one of them clearly the future, and a migration nobody had time to do by hand.
On 11 August GitHub added the button. Settings → Branches, then "Convert to ruleset" on an individual classic rule, and GitHub maps the configuration across.
What it converts
GitHub maps your existing branch protection configuration — including required reviews, status checks and push restrictions — into equivalent ruleset rules.
It is opt-in rather than automatic, and it works one rule at a time. That is the right call for a change that alters who can merge what, but it does mean an organization with many repositories is looking at a real amount of clicking, not a single migrate-everything action.
Why rulesets are worth moving to
The conversion is only worth doing because the destination is genuinely better. Four things rulesets do that classic branch protection does not:
- Pattern matching across multiple branches, instead of a rule per branch name
- Layered policies, so several rulesets can apply to the same branch and all must pass
- Management at the organization and enterprise level, not just per repository
- Fine-grained bypass permissions for specific users, teams and apps — which is what makes an emergency exception auditable instead of a shared admin account
The bypass model is the real upgrade
Classic branch protection had a blunt answer to "who can ignore this": administrators. That collapses two different things — the person who maintains the repository and the person who needs to push a fix at 2am — into one permission.
Rulesets let you name who can bypass, and this week's other release makes that visible: organization-level rule insights, in public preview since 12 August, reports allowed, failed and bypassed runs across every repository and highlights the ones with the most bypasses.
Converted rules feed that dashboard. Classic branch protection rules are a blind spot in it. That, more than any individual feature, is the argument for doing the conversion sooner rather than later.
Before you click convert
Two things GitHub's announcement does not spell out, so verify rather than assume:
It does not say what happens to the classic rule after conversion — whether it is removed or left in place. Check the branches settings afterwards, because two overlapping protections that both apply is a confusing state to debug later.
It also does not state which roles can run the conversion or set a deadline for classic branch protection. Treat this as a migration you should schedule, not one that is being forced on you — and convert one non-critical repository first to see exactly what the resulting ruleset looks like before you touch the branch that matters.