Diff Before Opening a PR: The Habit That Reduces Review Comments

You just opened the PR. Two minutes later, the first comment arrives: "forgotten console.log on line 47." You know you could have caught that if you'd read the diff before clicking "Create pull request."

This cycle — open PR, receive obvious comment, fix, force the reviewer to look again — is more expensive than it seems. This post is about the habit that breaks it.

What changes when you read your own diff

When you write code, you're in context. You know why each line is there, what you were thinking, what you tested. When you open the diff — especially in a visual interface with colors — you change perspective. You start seeing what will be reviewed, not what was written.

This perspective shift is real and small things become immediately visible: the debug console.log, the variable that was renamed in three of four places, the comment that became outdated after the refactoring, the config file that shouldn't be in the PR.

It's not that you were being careless. It's that in the context of writing, you weren't looking at the result — you were looking at the process. The diff forces the view of the result.

The real cost of skipping this step

An obvious comment on a PR isn't just a two-minute fix. It's:

• The reviewer had to open the PR, read the context, identify the problem, and write the comment
• You need to return to the context of what you were doing, fix it, commit, and re-request review
• The reviewer needs to look again — even just to mark the comment as resolved

In teams with synchronous review, each extra cycle can cost hours of waiting. In async teams, it can cost an entire day of delay.

The math is simple: five minutes of self-review before opening the PR can eliminate an entire review cycle.

git diff on the command line vs visual interface

For self-review, the visual interface wins. git diff in the terminal is useful for inspecting specific files or comparing branches, but for a complete review of what you're about to submit, a side-by-side visualization with addition and removal highlighting is more efficient.

# See what's staged (what's going into the commit)
git diff --staged

# See everything that changed relative to main
git diff main...HEAD

The problem with the terminal is that the output is linear — you scroll through a long file without the visual anchor of "this was added" vs "this was removed." For large diffs, there's a tendency to lose attention in the middle.

The visual interface solves this. You see the before and after side by side, and the human eye is good at identifying differences when it has both versions in parallel.

What to look at in the diff (practical checklist)

It's not a deep technical review — that's the reviewer's job. It's a cleanup before delivery.

What you're looking for:

• Forgotten debug: console.log, print, var_dump, dd(), breakpoints
• Files that shouldn't be in the PR: .env, local config files, auto-generated files
• Outdated comments: you renamed the function, but the comment above still mentions the old name
• Dead code: a function you wrote and didn't use, a variable declared and never read
• Scope creep: changes that aren't related to the PR's objective — an extra refactor you did "while you were there"

That last one is relevant because silent scope creep is what turns focused PRs into hard-to-review PRs. If you noticed you made an extra change that makes sense, it's worth creating a separate PR or at least explicitly documenting it in the description.

Smaller PRs as a natural consequence

When you look at the diff before opening, you naturally ask yourself: "does this change in file X relate to what I'm submitting?" If the answer is no, you start separating.

It's not an imposed rule — it's a side effect of the habit. The visual diff makes the scope concrete. It's easier to defend "this PR does one thing" when you just looked at it and confirmed that.

Smaller PRs have faster review, less chance of conflict, and more readable history in git log. This isn't new — every team knows this. What self-review does is create natural pressure to respect this principle.

The habit worth cultivating

The process is simple: before clicking "Create pull request," open the diff. Read each file as if you were the reviewer. Fix what you find. Only then open the PR.

It doesn't need to be long. Small diffs take two minutes. Large diffs — which are already a warning sign — take five or ten. In both cases, time spent before tends to be less than time recovered in the review cycle.

It's the kind of habit that, once you adopt it, makes it obvious you weren't doing it before.

Note: the editorial content ends here. What follows is a recommendation for a tool related to the post's topic.

Related tool

To review diffs outside the terminal — especially useful when comparing versions of a copied file, comparing outputs from two environments, or reviewing changes in contexts without Git — use the Diff Checker. You paste both versions and see the differences highlighted side by side, without needing a repository or CLI.