Dismiss stale approvals invalidates a pull request approval when the code changes after it was given. Without it, an author can get a harmless looking change approved, then push something different, and the earlier approval still counts toward the merge.
The scenario
A developer opens a small pull request. A reviewer reads it and approves. The developer then pushes another commit that touches an unrelated file, or the same file in a worse way. If approvals persist, the merge button is already unlocked.
This is not only a malicious case. Honest follow up fixes made after approval are the usual source. Either way, the reviewer did not see the final code.
What GitHub's setting does
The branch protection documentation says approvals are invalidated when the diff changes after approval. It lists a new push, using the Update branch action, or a related merge into the target branch as triggers. Changes to the merge base can also invalidate them.
One caveat from the same page: manually pushed merge commits may fail under this setting unless they exactly match what GitHub would generate.
The alternative and its trade off
There is also a last pusher approval option that requires approval from someone other than the person who pushed most recently. The documentation says it avoids dismissing stale reviews, but is less safe against unreviewed content being added to approved pull requests.
Choose by team size.
- Larger teams with fast reviews: dismiss stale approvals. Re review costs little.
- Two person teams: last pusher approval may be more workable, since a re review needs the one other person.
The cost people complain about
Re approving after a rebase is annoying. Reduce it:
- Keep pull requests small, so a re review is minutes. See small pull requests help reviewers catch more.
- Ask authors to batch follow ups, and to say in a comment what changed since the approval.
- Rebase before asking for review, not after.
Do not rely on it alone
The setting protects the approval. It does not check what the approver understood. Combine it with required status checks and owners on sensitive paths.
What to write in your engineering policy
"A pull request approval is valid only for the commit it was given on." That one sentence is easy to explain to an auditor and easy to test: push a change and watch the approval disappear.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
How to test your own settings
Open a throwaway pull request in a test repository, get an approval, then push one more commit. Look at the review status. If the approval still shows and the merge button is green, the setting is off for that branch.
Also test the edge case the documentation mentions: update the branch from the base. Some teams are surprised to find approvals reset after that action, and prefer to rebase before requesting review. Knowing how your own repository behaves avoids confusion later.
Quick check
Does a base branch merge dismiss approvals?
According to the GitHub documentation, a related merge into the target branch can invalidate approvals, and changes to the merge base can too.
Sources
Last reviewed: 19 October 2026.
