Branch protection and change approval
Protected branches turn a team's change rules into settings the server enforces: changes arrive only through pull requests, with a number of approving reviews and passing status checks, force pushes and deletions are blocked, and the rules can apply to administrators too. They give the review and approval evidence that mainframe change control expects.
Rules GitHub can enforce on a branch
| Rule | What it does |
|---|---|
| Require a pull request before merging | No direct pushes; a set number of approving reviews is needed |
| Dismiss stale approvals | An approval is dropped when new commits change the pull request |
| Require review from Code Owners | A listed owner of the changed files must approve |
| Require status checks to pass | Named checks must succeed; the strict form also needs the branch up to date with its base |
| Require conversation resolution | Every review comment must be resolved first |
| Require signed commits / linear history | Only verified signed commits; no merge commits on the branch |
| Do not allow bypassing the above settings | The rules apply to administrators too |
| Allow force pushes / allow deletions | Both are off by default on a protected branch |
GitHub rulesets apply the same kinds of rules to many branches or tags at once, for example every release/* branch, and several rulesets can apply together; when they define the same rule differently, the strictest one counts.
Status checks
A status check is an automated job that reports on a pull request, for example compiling the changed COBOL, scanning JCL, or running unit tests. When it is required, it must succeed (or be skipped or neutral) before the merge button works. A green check proves what that job tests, and nothing more: it will not notice that a step deletes the wrong file.
Approvals as change control
Mainframe sites have always separated who writes a change from who approves it. On a Git platform the evidence is the pull request: who reviewed which commit, what checks ran, and who merged it. Rules such as required reviews, dismissing stale approvals and asking for the most recent push to be approved by someone other than the person who pushed it make that separation real. A CODEOWNERS file adds the right specialists, for example the team that owns shared copybooks.
Force pushes and the admin button
A force push replaces a remote branch with your version and can silently discard other people's commits. Git refuses non-fast-forward pushes unless you force them; protected branches block force pushes altogether by default. Administrators can often bypass protection, for example with gh pr merge --admin; turning on "Do not allow bypassing the above settings" removes that escape hatch, so even an urgent change goes through review.
By default, what does GitHub do with a force push to a protected branch? (one word)
Show a hint
Allow force pushes is off by default.
Show the solution
It blocks it: force pushes are blocked on protected branches unless the setting allows them.
Common mistakes
Checks test what they were written to test. A person still has to read the change.
It skips the review that change control relies on. Ask a second reviewer instead.
It rewrites history others have. Tidy your own branch before you share it, or use a new commit.
What you will see at work
- Auditors increasingly ask for pull request records as evidence of review for mainframe changes, alongside or instead of change tickets.
- Typical rules on main: one or two approvals, stale approvals dismissed, required build check, code owners for shared copybooks.
- Emergency fixes still go through a pull request; the reviewer is simply found quickly, and the change record says who approved.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.