`git range-diff` Is the Review Command You Need After a Rebase So Reviewers Can See What Really Changed
A practical guide to `git range-diff` for developers who need to compare two versions of a branch, especially after rebase or review feedback, without making reviewers decode history by hand.
Why this command matters: after a rebase, force-push, or major review update, the biggest question is rarely “what does the branch look like now?” The real question is “what changed between the old version of the branch and the new one?”
What git range-diff actually does
The Git docs describe git range-diff as comparing two commit ranges, often two versions of a patch series. That wording is important. This command is not just another regular diff. It is designed to compare serieses of commits and line up corresponding patches.
A simple example shape from the docs is:
git range-diff old-base..old-tip new-base..new-tipThe docs also describe shorthand forms like:
git range-diff base old-tip new-tipThe core idea is that Git tries to match related commits between the two ranges, then shows how those commits changed.
That makes it much more useful than a plain diff when a branch has been rebased, split, reordered, or amended during review.
Why ordinary diffs stop being helpful
A normal git diff tells you the content difference between two snapshots. That is useful, but after a force-pushed PR it often hides the human question reviewers care about:
- which commits stayed the same
- which ones were rewritten
- which ones disappeared
- which new ones were added
git range-diff is better because it keeps the commit-series perspective intact.
This is exactly what you want after review feedback. Reviewers are not only reading code. They are checking how your patch stack evolved.
A practical review scenario
Suppose you submitted a branch for review, got comments, rebased onto the latest main, squashed two commits, split one noisy commit into three cleaner ones, and force-pushed.
Now the reviewer has a problem:
- the branch hash changed
- commit ids changed
- the PR diff might still look large
- the question “what changed since last review?” becomes expensive
This is where git range-diff earns its place. It gives a commit-aware comparison between the earlier version and the updated one.
That makes review iteration much less painful.
Why this command improves PR discipline
Teams that rebase often but never use range-diff quietly create review fatigue. Reviewers have to reconstruct history changes mentally, which means:
- slower reviews
- less confidence
- more missed changes
- more resistance to clean rebasing
When developers attach a range-diff summary in review notes after a force-push, they reduce that burden immediately.
This is one of those commands that does not just help you locally. It helps the people downstream of your history edits.
What it is actually matching
The Git docs explain that the command tries to find commits from both ranges that correspond with each other by comparing their patches. That matters because it means range-diff is smarter than simple commit-id comparison.
If a commit was amended but is still conceptually “the same patch, updated,” Git can often align it with its counterpart.
That is why the output feels much more review-friendly than raw history comparison.
The best moment to use it
Use git range-diff when you have:
- rebased a branch
- force-pushed a PR
- reordered or split commits
- revised a patch series after feedback
It is less about debugging code and more about debugging branch evolution.
That may sound niche, but on teams that care about clean history, it becomes a very practical skill.
The limitation to remember
The Git docs explicitly note that the output of range-diff is subject to change. That is a reminder not to build fragile tooling around the exact visual format. Treat it as a review aid, not a machine-stable API.
This is fine. Human-readable tools do not need to be rigid formats to be valuable.
Final recommendation
If you regularly rebase or force-push reviewed branches, learn git range-diff and start using it to explain what changed between patch versions. It is one of the best ways to make rewritten history easier for other humans to trust.