Not if you turn on the right setting. GitHub's optional rule, require approval of the most recent reviewable push, demands at least one approval from someone other than the person who made the latest push. It does not dismiss older approvals, so it solves self-approval, not the problem of late changes.
What the setting actually checks
Classic required reviews count approvals, nothing more. If two people approve and a third person then pushes a new commit, the approvals can still stand, and the pusher might even be one of the approvers. That gap is where a change slips in after review.
The most recent reviewable push rule closes part of it. After the latest push, the pull request needs an approval from someone who did not make that push. Earlier reviewers can approve again to satisfy the requirement. GitHub's documentation states that stale reviews are not dismissed under this setting.
The comparison that matters
Two settings sound similar and behave differently.
| Setting | What it blocks | What it leaves open |
|---|---|---|
| Require approval of the most recent reviewable push | The last pusher being the only approver | Earlier approvals stay valid after new commits |
| Dismiss stale approvals | Merging content nobody reviewed | A pusher can re-approve if reviewer rules allow it |
GitHub's own page notes that dismissing stale reviews is the safer choice if you worry about unapproved content being added to an approved pull request. If you can afford the extra clicks, enable both.
A short rollout path
- Open the branch protection rule or ruleset for your default branch.
- Turn on required pull request reviews with at least one approval.
- Enable approval of the most recent reviewable push.
- Enable dismissal of stale approvals if your team can live with re-review.
- Test with a throwaway pull request and a second account, so you see the block yourself.
Do this on the paths that matter first, such as workflow files and deployment config, then widen it. A rule nobody can work with gets bypassed, and bypass habits are harder to undo than a slow rollout.
Where Safeguard fits
Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through the pull request gate and watch which condition blocks the merge; compare it with the review rules above.
Click through it at your own pace, or open it full screen.
Quick check
Does this stop an admin from merging?
Not by itself. Who can bypass is controlled by the branch protection or ruleset bypass list, which you should keep short and review.
Is one approval enough?
The setting only requires approval from someone other than the last pusher. How many approvals you need is a separate choice based on risk.
Sources
Last reviewed: 19 October 2026.
