Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A branch or pull request is a container; the thing a reviewer needs to understand is the logical change inside it. In “I Miss Reviewing Changes, Not Branches,” Mauro Damian Perez Garcia argues for organizing review around one decision at a time—so a reviewer can assess it, discuss it, and disagree before it is buried in a larger bundle.
Why review the change instead of the branch?
A branch-centered review treats everything gathered on that branch as one unit. That can be convenient, but it may combine work that has different purposes: a rename, a refactor, a behavior change, and a new feature. Perez Garcia argues that this makes it harder to see which lines carry risk and what a reviewer is actually being asked to approve.
In the author’s account, a large review can also make disagreement more expensive: one objection may hold up a broad bundle of work, even if the concern applies to only one decision. The point is not that every branch is too large, or that a particular review size guarantees a better result. It is that the branch boundary does not necessarily match the best boundary for understanding and discussing a change.
Free tools Windows power users keep installed
One-click scans. No signup required.
How stacked changes can make review easier to follow
When several changes depend on one another, the author describes splitting them into a sequence that exposes each decision. For example, a stack might introduce an interface first, implement it in a second change, and migrate callers in a third. Each step depends on the earlier one, but reviewers can consider the interface, implementation, and migration as distinct parts of the work.
#1 Best Overall
This can bring design discussion forward. Reviewers can weigh in on the interface before the implementation and caller changes make it more difficult to revisit. Stacking is useful only when the sequence clarifies the work; splitting a coherent change into arbitrary fragments can instead make its purpose harder to see.
Practical habits for change-centered reviews
- Make commits understandable on their own. A reviewer should be able to follow the reasoning behind each commit, rather than reconstructing it from an undifferentiated diff.
- Separate mechanical edits from behavior changes. Renames or other mechanical work are easier to assess when they do not obscure lines that alter what the software does.
- Raise interface questions early. Where an interface is a meaningful design decision, present it before implementation and caller migration so discussion can happen while that decision is still easy to change.
- Use stacked pull requests when the platform supports them. Represent dependent steps explicitly, such as interface, implementation, and migration, instead of asking reviewers to infer the sequence from one large branch.
- Point reviewers to the risky part. State which portion deserves the closest attention; do not make reviewers guess where a consequential behavior change is hidden.
As Perez Garcia puts it, “None of this requires new software.” The practices are about how work is divided and explained, although the tools a team already uses affect how comfortable the workflow feels.
What can make a stack difficult to use?
Stacked review adds coordination work when an earlier change is revised and later changes must be rebased on top of it. Rewriting commits can also affect whether existing review comments remain attached to useful context. Before adopting the workflow broadly, a team should consider how its hosting platform handles dependent reviews, rebases, and comments after a force-push.
That is a practical trade-off, not proof that one platform or review style is best for every team. If the tooling makes dependencies and rewritten history confusing, a simpler change boundary may be easier for reviewers to use. The goal is to make the reasoning legible, not to follow a Git convention for its own sake.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.The idea behind “I Miss Reviewing Changes, Not Branches”
Perez Garcia’s essay is an argument drawn from the author’s experience, not a measured comparison of review workflows. Its central recommendation is to make one decision easy to understand before bundling it with the next. As the article closes: “The goal was never to have opinions about Git. It was to make it easy for a colleague to understand one decision at a time, and to disagree with it while disagreeing is still cheap.”
Read Mauro Damian Perez Garcia’s original essay on DEV Community.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
