skip to content

On a GitHub pull request, what happens to existing approvals and inline comments when the author pushes new commits?

level: middleimportance: should knowfreq 48%

answer

  1. Reviews are pinned to a commit
  2. Approval survives unless configured otherwise
  3. An objection is the reviewer's to withdraw
  4. Comments collapse when their lines move
  5. Dismissal requires a stated reason

basics

~20 s

By default approvals survive a new push and keep counting. Inline comments on lines that changed are marked outdated and collapse. A repository can opt in to dismissing stale approvals on every push, and anyone with write access can dismiss a review manually with a reason.

solid answer

~50 s

Pushing does not, by itself, undo review state. An **approval stays valid** and continues to satisfy a required-approval rule, even if the new commits changed everything the reviewer looked at — which is exactly why repositories can enable **dismissal of stale approvals on new commits**, turning every push into a reset that forces a fresh look. A **changes-requested** review is the opposite: it survives the push regardless, because the author fixing something does not retract the reviewer's objection. The author clears it by getting an approving review, or someone with write access **dismisses** the review, which requires a reason and moves it to a dismissed state that no longer counts. **Inline comments** anchored to lines that the new commits changed become **outdated** and collapse in the conversation; they stay in the timeline as history. Separately, conversations can be marked resolved, and a repository may require every conversation resolved before merging.

code

json · 7 lines
json
{
  "id": 481920,
  "user": { "login": "omar" },
  "state": "DISMISSED",
  "commit_id": "9f3a2c1d7b4e5a60c8d29b17e4f0a3d5c6b81920",
  "body": "Please guard the null case before merging."
}

go deeper

for a junior

Know that pushing a fix does not clear a reviewer's requested changes, and that after addressing feedback you should re-request review rather than waiting silently.

for a middle

Explain the default behaviour precisely — approvals persist, changes-requested persists, comments outdate — and name the repository option that dismisses stale approvals on every push.

for a senior

Show that you have operated this: the churn cost of stale-approval dismissal, the outdated-but-unresolved trap on fast-moving branches, and using the force-push compare link to verify a rebase really was one.

for a principal

Own the policy per repository class: where approval provenance must be exact, where the re-approval treadmill would degrade review quality, and how you keep dismissal a visible, accountable act rather than routine.

## Reviews are pinned to a commit Every submitted review on a GitHub pull request is associated with the head commit as it stood when the review was submitted. That is what makes the concept of a **stale** review meaningful: an approval given at commit `abc123` says nothing about `def456`, even though it keeps counting until something changes it. ## Approvals: valid until dismissed The default is permissive. Push new commits and the existing approval remains, still satisfying a required-approval rule. This is convenient when the push is a rebase or a typo fix and infuriating when it is a rewrite, so GitHub offers the opt-in behaviour: **dismiss stale pull request approvals when new commits are pushed**, configurable in classic branch protection and in the equivalent ruleset option. With it enabled, every push to the head branch drops all existing approvals and the pull request needs fresh sign-off. That setting is a real tradeoff rather than an obvious win. Enabled, it guarantees that what was approved is what merges — the property you want on anything security- or compliance-sensitive. It also means a whitespace fix at the end of a long review cycle sends everyone back to square one, and on a busy repository it converts approvals into a treadmill people learn to rubber-stamp. Many teams enable it on the repositories where provenance matters and leave it off elsewhere; a middle path is to combine a permissive default with a code-owner requirement on the paths that genuinely need re-approval. ## Changes requested: sticky by design A `CHANGES_REQUESTED` review does not clear when the author pushes a fix. The reviewer's objection is theirs to withdraw, so it persists until they submit an approving review or someone with write access **dismisses** it. Dismissal requires a written reason, which lands in the timeline — deliberately, since silently discarding a colleague's objection should leave a record. A dismissed review takes the `DISMISSED` state and stops counting toward requirements. The author's normal move after pushing a fix is **re-request review**, which returns that reviewer to a pending state and notifies them. Without it, a fixed pull request can sit for days because the reviewer has no signal that anything changed. ## Inline comments: outdated, not deleted A review comment is anchored to a file, a line, and a diff position. When new commits change that region, GitHub can no longer place the comment in the current diff, so it marks it **outdated** and collapses it. Nothing is lost — the comment stays in the conversation history and the original context can still be expanded — but it disappears from the file view, which is how genuine feedback quietly goes unaddressed on a fast-moving branch. Separately from outdating, conversations can be **resolved**, which collapses the thread and marks it dealt with; a repository can require all conversations resolved before merging, so resolution becomes a gate rather than a courtesy. The two states are independent: a comment can be outdated but unresolved (the code moved, the concern did not), and that combination is the one that slips. ## Force-pushes A force-push to the head branch is still a push: stale-approval dismissal fires if enabled, and comments outdate as usual. GitHub records a force-push entry in the timeline with a link comparing the before and after heads, which is the practical way a reviewer checks that a "rebase" was really only a rebase. Reviewers of an actively rebased branch should use that link rather than re-reading the whole diff. ## What this means in practice For authors: after addressing feedback, push, resolve the conversations you actually handled, and re-request review. Do not resolve someone else's unaddressed thread to clear the gate. For reviewers: when returning to a pull request, look at what changed since your review rather than at the whole diff again, and expand outdated comments before approving — an outdated comment is not an answered one. For repository owners: decide deliberately whether approvals should survive pushes on this repository, and know that the answer differs between a payments service and an internal dashboard.

  • What is the tradeoff of enabling dismissal of stale approvals on every push?
    It guarantees that the approved code is the merged code, which is what you want for security- or compliance-sensitive repositories. The cost is churn: a trivial fix after a long review cycle resets every approval, and on a busy repository repeated re-approval trains people to click without reading. Many teams enable it selectively rather than organization-wide, or pair a permissive default with code-owner review on sensitive paths.
  • What is the difference between an outdated comment and a resolved conversation on GitHub?
    Outdated is automatic and positional: the lines the comment was anchored to changed, so GitHub collapses it out of the file view. Resolved is a deliberate act saying the discussion is settled. They are independent, and the dangerous combination is outdated-but-unresolved — the code moved while the concern was never addressed, and it has already disappeared from the diff view.
  • A reviewer requested changes and has been unreachable for a week. What are the author's options?
    Get the required approvals from other eligible reviewers, and have someone with write access dismiss the stale review with a written reason that lands in the timeline. Dismissal is deliberately visible because overriding a colleague's objection should be on the record. The healthier fix is a team norm on review turnaround so an absent reviewer does not park work indefinitely.

saying these in an interview costs you the question

  • Thinks a new push automatically clears approvals
  • Believes pushing a fix retracts requested changes
  • Treats an outdated comment as an addressed one
  • Resolves other people's threads to clear the gate
  • Assumes dismissing a review leaves no record

context

resolving links…