Because an approval applies to the diff that was reviewed, not to whatever the branch becomes later. If stale approvals are not dismissed, a contractor can get a pull request approved, push more code, and merge. Turning on dismissal means any change to the approved diff needs a new review.
What GitHub's setting does
GitHub's documentation describes an optional branch protection setting that dismisses stale pull request approvals when commits are pushed that affect the diff. GitHub records the state of the diff at the moment of approval. If the diff changes from that state, for instance because a contributor pushes new changes or clicks Update branch, or because a related pull request is merged into the target branch, the approving review is dismissed as stale and the pull request cannot merge until someone approves again.
It is a simple rule, and it closes a quiet gap.
The attack it prevents
- A contractor opens a clean pull request.
- A reviewer approves it.
- The contractor pushes one more commit that adds something unreviewed.
- They merge, and the approval is still on file.
GitHub names this in its guidance: if you are concerned about pull requests being hijacked, where unapproved content is added to approved pull requests, dismissing stale reviews is the safer choice. The same pattern can happen innocently, for example a late fix that nobody re-read.
The alternative, and the trade off
GitHub also offers a setting that requires the most recent reviewable push to be approved by someone other than the person who pushed it. Stale reviews are then not dismissed, and the pull request remains approved as long as someone other than the last pusher approves. Reviewers who already approved can approve again after the latest push.
| Setting | What happens on a new push | Reviewer load | Hijack risk |
|---|---|---|---|
| Dismiss stale approvals | Approval removed, new review needed | Higher on busy pull requests | Lowest |
| Require approval of the latest push by another person | Approval kept, but someone other than the pusher must approve the final state | Lower | Low, but earlier approvals stay |
| Neither | Approval stays regardless | Lowest | Highest |
GitHub frames the second option as a compromise for complex pull requests that need many reviews. It is reasonable for a long running staff pull request. For contractor pull requests on sensitive paths, dismissing stale approvals is the stronger default.
When to pick which
- Sensitive paths and short pull requests. Dismiss stale approvals. The review burden is small.
- Large pull requests needing many reviewers. Consider requiring approval of the latest push by another person, and keep an eye on what is added late.
- Anything touching workflows, dependencies or access files. Dismiss stale approvals and require code owner review. See CODEOWNERS for workflow files.
Rulesets and admins
Protection can be configured with branch protection rules or rulesets, which GitHub also lets you bypass for chosen roles or teams. Check who holds bypass, because an admin bypass makes any of the settings above optional. The post on branch protection and admin bypass explains why this matters, and rules versus rulesets compares the two.
Make reviews quick instead of loose
Reviewers resist this setting when pull requests are large. Ask contractors to keep pull requests small and to avoid force pushes after review. Small changes make a new approval a thirty second task, and the safeguard costs almost nothing.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that the gate runs on the pull request as it stands now, which is the same idea as re-reviewing a changed diff.
Safeguard's policies and gates add automated checks that rerun on each new commit, and compliance and evidence automation can keep the settings on record. See the free scan.
Quick check
Does Update branch count as a change?
According to GitHub, clicking Update branch can change the diff and cause the approving review to be dismissed as stale.
Is the latest-push approval setting as strong?
It is a compromise. Earlier approvals stay, so GitHub says dismissing stale reviews is safer if you worry about hijacked pull requests.
Sources
Last reviewed: 19 October 2026.
