Create a repository ruleset that targets your release and hotfix branch name patterns, require pull request review and passing checks, block force pushes, and limit who may bypass. Then even a late night hotfix goes through the same gate as normal work.
What a ruleset does
GitHub's documentation describes rulesets as a way to control how people interact with branches and tags in a repository. Rules can apply to branches whose names match a pattern, and you can grant bypass permissions to chosen roles or teams. When several rulesets apply to the same branch, the documentation says the most restrictive version of each rule wins, which makes layering safe.
Naming convention is what makes this practical. If hotfix branches always start with the same prefix, one pattern covers all of them without per-branch setup.
A setup for release work
| Target pattern | Rules | Bypass |
|---|---|---|
| release/* | Require pull request, one or two approvals, required status checks, no force push, no deletion | None, or a small named group |
| hotfix/* | Same, plus require a linked ticket in the description | None |
| Tags matching v* | Restrict creation and deletion | Release owners only |
Steps
- Pick and document the branch naming scheme. For example release/2.4 and hotfix/2.4.1-short-name.
- Create a ruleset that targets those patterns.
- Require at least one approving review, and require that the approver is not the last pusher, so the author cannot approve their own latest change.
- Require the status checks that matter: build, tests, vulnerability scan.
- Disable force pushes and branch deletion on release branches.
- Decide who can bypass, if anyone. Keep that list short, and note that every bypass should leave a record.
- Test with a throwaway branch. Try to push directly and confirm it is blocked.
The emergency question
What if the approver is unreachable and production is down? Pre-agree an emergency path: a small group with bypass permission who must write a note after each use. A planned bypass with a record is better than an improvised one with none, and far better than turning protection off during the incident and forgetting to turn it back on.
Mistakes to avoid
- Protecting main but leaving release branches open, which is where hotfixes land.
- Making the bypass group everyone with admin rights.
- Requiring checks that are often broken, which teaches people to bypass.
- Never testing the rules until the first real emergency.
Review the log
After each use of the bypass, check what was pushed. Review the list monthly and remove names that no longer need it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a failed check blocks the merge, and think about which checks a release branch should require.
Safeguard's policies, gates and guardrails can add security checks to those required checks. A free scan is at gold.safeguard.sh/scan.
Quick check
Can two rulesets apply to one branch?
Yes. GitHub's documentation says the most restrictive version of a rule applies when they overlap.
Should anyone be able to bypass the rules?
Keep the group small, with a required note after each use. Having none is also valid for small teams.
Sources
Last reviewed: 19 October 2026.
