How to Re-review a Pull Request Without Starting Over
Re-reviewing a pull request is a race against context decay. How to inspect what changed since your last review without re-reading the entire diff from scratch.
A few days ago, I was reviewing a backend pull request where an edge case had been left unhandled. I left a comment pointing it out, and the author came back the next day with a clean follow-up commit and a quick reply on the thread. Opening that specific commit diff took two minutes: the fix was there, the test was there, and I could approve it without reloading the entire pull request into my head.
That is what you hope for on a re-review.
In practice, it rarely goes that way.
Don't start with the diff. Start with the conversation.
When you open a pull request for a second look, the natural impulse is to click straight to "Files changed".
If you do that, you're immediately trying to rebuild your mental model of the entire branch from scratch. By the time a PR comes back for re-review, you've usually spent hours or days on other work. You forget why a helper took an optional parameter, or how the error handling chained through the service layer. Staring at raw lines of code doesn't bring that context back; it just burns time re-learning code you already evaluated.
Over time, I've ended up with a simple rule: don't start with the diff. Start with the conversation.
The open comment threads give you an immediate index of what actually needed work. Reading the author's reply tells you how they approached the problem before you ever touch the code. If they wrote that they added a fallback, or explained why a suggested fix didn't work in practice, you get the context back in thirty seconds without having to deduce their intentions from diff lines.
From there, you can inspect the actual delta:
- Walk the threads first to understand the author's intent.
- Jump directly to the files where your comments were located, or open the specific commits addressing them.
- Check the immediate blast radius: did the new branch or error handling change what a neighboring caller expects?
- Reset to a full review only when the delta is no longer trustworthy.
This also lines up with research on modern code review: understanding the change and recovering missing context are recurring challenges for reviewers, while studies on separating unrelated changes found measurable benefits during review.
Why the delta gets messy
If branches only received isolated fixup commits, an incremental check would be straightforward. But in practice, updates get messy in ways every developer recognizes.
Authors naturally clean things up while they have the file open. Someone goes in to fix the edge case you asked about, notices an awkward variable name or a missing null check nearby, and tidies that up too. It's well-intentioned, but now the commit is a mix of the requested fix and several drive-by improvements, leaving you to untangle which lines matter.
Multiple reviews also collide. When two or three people leave comments, the author usually addresses all of them before pushing. You open the PR hoping to check the edge case fix you asked about, but the commit also touches a database migration from someone else's suggestion.
And then there is pulling in main. If the branch sat for a few days, it's probably behind. The author merges or rebases to resolve conflicts, and suddenly the diff contains conflict resolutions in files you already approved. After a rebase or conflict resolution, "Changes since last review" isn't always the clean delta you hoped for. You're left with an altered diff and no simple way to separate what was changed for your comment versus what was rewritten to resolve a merge conflict.
The place where looking only at the commit diff can bite you is the blast radius.
The new lines might handle the edge case cleanly in that one function, but they might change an assumption in code you already approved yesterday. I usually check neighboring callers and related test files before deciding whether the delta is isolated enough, rather than re-reading every unchanged line in the pull request.
When to give up and start over
Sometimes there is no shortcut.
If the author had to rewrite the underlying abstraction, or if a rebase scrambled the history enough that you can no longer trust the delta, admit it early and do a fresh review of the affected modules. Skimming a confused diff hoping you will spot regressions is how bugs sneak into production.
The point of incremental review isn't to avoid doing a full review at all costs. It's to avoid doing one when nothing important outside the delta has changed.
Knowing when the ball is back in your court
Inspecting the code is only half the problem. You also have to notice that the PR is ready for you again.
GitHub shows the events, but it doesn't turn them into a simple "your turn / their turn" state. That leaves you to infer from commits, replies, and notifications whether there's actually something new for you to do. Authors end up pinging on Slack to announce their fix, or the PR can sit until someone remembers to check.
As we looked at in who owns the next move on a pull request and stop chasing pull request reviews in Slack, a pull request should only enter your active queue when there is an actionable change waiting for you.
This is part of what we designed into PR Flow. When you request changes, the pull request moves to Waiting. When the author pushes again, it comes back to Needs you marked as a re-review.
That doesn't make the re-review itself easier, but it solves the other half of the problem: remembering that there is something new for you to look at.