The approval no longer matches the code being merged, so the merge should stop until the updated diff is reviewed again. GitHub stale-review dismissal helps enforce that rule, and the merge request should include the reviewed head commit SHA. If the PR has advanced, GitHub returns a conflict instead of merging stale code.
Why an Approved Pull Request Stops Being Safe to Merge
Once a pull request changes after review, the approval is no longer evidence for the code that will actually merge. The practical break is review integrity: the reviewed snapshot and the merge candidate have diverged. That is why teams use stale-review dismissal, require a reviewed head commit SHA, and block merging until the updated diff is checked again.
A useful mental model is that approval is tied to a specific commit state, not to the pull request title or discussion thread. If the branch advances, rebases, or receives new commits, the earlier review can become stale even when the change feels minor. GitHub's conflict behavior is a guardrail that forces the stale state to be resolved before the merge proceeds.
Why the Reviewed Commit SHA Matters More Than the PR Itself
The reviewed head commit SHA is the strongest reference point because it identifies exactly what was inspected. Without that anchor, a PR can accumulate new code after approval and still appear "approved" in a superficial sense. The merge decision should therefore be based on the reviewed commit, the current diff, and whether the approval still covers the same contents.
This is especially important in high-churn branches, where a small approval delay can hide a meaningful change in scope. Even a single new commit can introduce different dependencies, logic paths, or security-relevant behavior. Stale-review dismissal makes the workflow stricter by invalidating approval when the underlying reviewed state no longer matches the merge target.
In practice, the reviewed SHA also gives teams an auditable record of what was accepted. That helps separate "code was approved" from "this exact code was approved," which is the distinction that matters when a merge is questioned later.
What GitHub Is Protecting Against When It Returns a Conflict
When GitHub returns a conflict instead of merging stale code, it is signaling that the branch state has moved enough that the previous approval can no longer be trusted as current. The merge blocker prevents silent drift between review and release, which is where bad surprises usually enter the main branch.
That control is less about convenience and more about correctness. If the PR changed after approval, the team should assume the review evidence is incomplete until the new diff is examined. A conflict is therefore a useful enforcement point, because it forces a fresh review rather than relying on stale human memory.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | PR approval must track branch changes that alter the reviewed code. |
| AC-3 — Access Enforcement | Merge approval gates who can introduce reviewed code into the protected branch. | |
| Recommendation — Require re-review whenever a protected pull request changes after approval. Enforce branch rules so only current, reviewed changes can merge. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | Approved PRs are a software change control problem requiring revalidation after edits. |
| Recommendation — Revalidate approvals after any post-review code change before release. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Pull request review and stale-approval dismissal are secure SDLC controls. |
| Recommendation — Gate merges on current review state and protect the main branch from stale approvals. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Commit-bound review supports trustworthy code promotion and change integrity. |
| Recommendation — Bind approval to the reviewed revision and reject merges after branch drift. | ||
Practitioner Guidance
What to verify: Confirm that the approval matches the exact head commit that will merge, not just the PR conversation history. If the reviewed SHA is different from the current head, treat the approval as expired and require re-review.
Decision rule: If a PR has moved after approval, stop the merge flow, dismiss stale approvals where your platform supports it, and require the new diff to be reviewed before merging. Do not use "approved earlier" as a substitute for current review coverage.
What good looks like: The merge pipeline only accepts a PR when the reviewed commit, current head commit, and merge candidate are aligned. That keeps review evidence tied to the exact code that enters the protected branch.
Practitioner takeaway: The core control is not the approval itself, but the binding between approval and an immutable reviewed revision. Break that binding, and the merge must pause until review catches up.
Related resources from NHI Mgmt Group
- What happens when code quality gates are used only after merge instead of in the pull request?
- How should merchants respond when a shipping address changes after an order has already been approved for fraud review?
- Why do IDE, CLI, and pull request scans reduce risk more effectively than checking code only after merge?
- What breaks when agents can trigger their own next tasks after a merge?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
