Someone posted a tool that brings a Gerrit-style review workflow to GitHub and the other forges, and I felt a small pang of recognition. Not because I want to relitigate which review tool is best, but because it named a frustration I had stopped noticing.
The pull request model quietly conflated two different things: the branch you are working on and the unit of change you want reviewed. For a long time I assumed that was just how code review works. It is not. It is one choice among several, and it has costs we have all agreed to pay without discussing.
The unit of review should be a decision, not a container
In a change-centric workflow, the thing under review is a single logical change. It has an identity that survives rewriting. You can amend it, rebase it, improve it after feedback, and the review conversation stays attached to the change itself rather than to a pile of commits that happen to share a branch name.
The practical consequence is that stacking becomes natural. Change A introduces the interface. Change B implements it. Change C migrates the callers. Each one is small, each one is reviewable in ten minutes, and each one can move forward at its own pace.
In a branch-centric workflow, that same work tends to collapse into one pull request with forty files in it, because splitting it means juggling branches, base branches, and the fun of every rebase invalidating the review below. I have watched excellent engineers batch up a week of work into a single reviewable lump purely because the tooling made the alternative annoying.
We then blame the reviewer for skimming. The reviewer is not the problem. Nobody reads forty files carefully. They read the first three and approve the rest on trust.
What large reviews actually cost
The cost is not just missed bugs, though there are missed bugs.
It is that a large review cannot be honest about intent. When a diff contains a rename, a refactor, a behavior change, and a new feature all at once, no reviewer can tell which lines are load-bearing. The refactor camouflages the risky change. I have shipped bugs this way and I have approved bugs this way, and in both cases the review technically happened.
It is also that a large review makes disagreement expensive. If I object to one design decision inside a big pull request, I am blocking a week of someone's work. So I soften the comment, or I leave it as a "nit," or I say nothing. Small changes make it cheap to disagree, which means disagreement actually surfaces.
And it is that revert becomes a blunt instrument. Reverting a focused change is a five-minute operation. Reverting a mega-branch means untangling four unrelated things at the worst possible moment.
You can get most of this without switching tools
Here is the part I want to be practical about. I am not going to convince an organization to migrate its review infrastructure, and I would not necessarily recommend it.
But most of the benefit comes from habits rather than tooling:
- Write commits that each stand alone, so a reviewer can walk them in order and follow the reasoning.
- Split mechanical changes from behavioral ones. A rename-only pull request is a gift. It gets approved in a minute and it makes the next diff readable.
- Open the interface change before the implementation, so the design conversation happens while it is still cheap.
- Use stacked pull requests when the platform supports them, even if the ergonomics are imperfect.
- Say in the description what you want reviewed. "The retry logic is the risky part; the rest is plumbing" saves everyone twenty minutes.
None of this requires new software. It requires treating review as a communication problem rather than a gate to pass through.
Where the tools still matter
That said, tooling shapes behavior more than intentions do. If rebasing a stack is painful, people will stop stacking, regardless of what the style guide says. If review comments do not survive a force-push, people will avoid force-pushing and let their history get messy instead.
So I am glad these alternative workflows keep getting built, even when they stay niche. They function as a running argument that the dominant model is a choice. Every time I use one, I come back to the mainstream flow noticing friction I had accepted as weather.
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.
Top comments (0)