With the right branch protection setting, nobody who pushed the latest commits to a pull request can supply the approval that counts. GitHub calls it requiring approval of the most recent reviewable push. For shared infrastructure repositories, it closes a simple gap: an approved change that was edited afterwards.
The gap it closes
A common flow is: author opens a pull request, a reviewer approves, the author pushes one more commit "just to fix a typo", and merges. The approval no longer matches the code. In application code that is a nuisance. In a shared Terraform module or CI template, the extra commit might widen a security group or change a role.
GitHub offers two related settings, and they do different things.
The two settings
From GitHub's protected branches documentation:
| Setting | What it does |
|---|---|
| Dismiss stale pull request approvals when new commits are pushed | Approvals are dismissed when the diff changes, such as new pushes, Update branch, or a related PR merging into the target |
| Require approval of the most recent reviewable push | The latest push must be approved by someone other than the person who pushed it |
The second one has a subtle point. GitHub says stale reviews are not dismissed by it, so the pull request stays approved if another reviewer approves the latest changes. Reviewers can also reapprove after the latest push to meet the requirement.
Used together, they give you two protections. An old approval is cleared when the diff changes, and the new diff needs a fresh approval from someone who did not write it. See what dismissing stale approvals protects.
Which to turn on for infrastructure repositories
For repositories whose changes can alter production, turn on both. For lower risk repositories, the second may be enough. Consider the cost: more re-reviews. The people who feel it are authors making small fixes late in a review. A short policy note helps: push all changes before asking for review, and expect re-review after any later push.
Setup steps
- Open the repository's branch protection (or ruleset) for the default branch.
- Require pull requests before merging and set the number of approving reviews.
- Enable dismissal of stale approvals.
- Enable approval of the most recent reviewable push.
- Require review from code owners so the right people approve. See CODEOWNERS pitfalls.
- Select "Do not allow bypassing the above settings", because by default admins and users with the bypass permission are exempt. See admins bypass by default.
- Test with a throwaway pull request to see what a reviewer sees.
Limits
These settings control who may approve, not whether the approval was careful. They also do not stop a person with bypass rights who has not been excluded. They apply to the branch, so a long lived team fork or a second repository can sidestep them. And they say nothing about what happens after merge, such as who runs the apply. For that, see environment approvals for apply.
Evidence value
Auditors and customers often ask who approved a change and whether the approver was independent of the author. With these settings enforced, the platform records the answer. See branch protection evidence for code integrity reviews.
Where Safeguard fits
Safeguard's policies and gates can hold pull requests until required checks pass, and compliance and evidence automation can collect review records. The approval rules themselves are configured in your source host.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate and look at what blocks a merge and what lets it through.
Quick check
Does this setting dismiss old approvals?
No. GitHub says stale reviews are not dismissed by it. Use the separate stale approval dismissal setting for that.
Do admins have to follow it?
Not by default. Admins are exempt unless you select Do not allow bypassing the above settings.
Sources
Last reviewed: 19 October 2026.
