Review quality collapses with diff size. A hundred-line change gets read carefully; a two-thousand-line change gets a scroll and an approval. Everyone knows this and large pull requests keep happening, because the work was genuinely large and splitting it seems to require either shipping broken intermediate states or maintaining parallel branches by hand.
Stacked diffs are the resolution: a chain of small pull requests, each building on the previous, each independently reviewable, merged in order.
What changed in 2026
- Platform support improved. Native handling of dependent pull requests got better, reducing how much external tooling the workflow requires.
- Dedicated tools matured. Command-line tools managing stack creation, restacking, and submission became reliable enough for everyday use.
- Agent-generated changes increased demand. As more code arrived in larger automated batches, splitting it into reviewable pieces became more valuable.
- The review-size evidence stayed consistent. Data continued to show defect detection falling as diff size grows, which keeps the argument simple.
How a stack works
| Stack position |
Contains |
Reviewed against |
| Base |
The trunk branch |
— |
| First |
Refactor or scaffolding |
Trunk |
| Second |
Core change |
First |
| Third |
Tests and edge cases |
Second |
| Fourth |
Documentation and cleanup |
Third |
Each pull request shows only its own diff, because it is compared against the one below it rather than against trunk. A reviewer looking at the third sees the tests, not the refactor from the first — which is what keeps each review small even when the total change is large.
Merging happens bottom-up. As each lands on trunk, the next rebases onto the new trunk and becomes the new bottom of the stack.
Where the friction is
Restacking. When review feedback requires changing the first pull request, everything above it must be rebased onto the amended version. Doing that by hand across a stack of five is tedious and error-prone, and it is the reason the workflow has a reputation for being painful.
Tooling solves this specific problem — a single command that rebases the whole stack and updates every pull request. Without such tooling the workflow is genuinely more trouble than it is worth for most teams, which is the honest caveat.
The second friction is platform support. Some review platforms handle dependent pull requests natively and show clean per-pull-request diffs; others show each pull request against trunk, which defeats the purpose by making every diff cumulative. Check this before adopting the workflow, because it determines whether reviewers see what you intended.
The third is team convention. A stack works when reviewers understand they are reviewing one link, not the whole chain, and when merges happen promptly so the stack does not sit accumulating rebase debt. That is a social agreement more than a technical one, and it fits naturally with the fast-merge norms of trunk-based development.
Common mistakes
- Stacking without tooling. Manual restacking is where teams give up.
- A platform that shows cumulative diffs. Each review becomes the whole change anyway.
- Long-lived stacks. Rebase debt accumulates; merge the bottom promptly.
- Stacks that are too deep. Beyond a handful of links, coordination cost rises sharply.
- Splitting arbitrarily. Each link should be coherent and ideally independently correct.
- Blocking the whole stack on one review. Reviewers should take links in order without waiting for the full chain.
FAQ
Should each link be independently deployable?
Ideally each should leave the codebase working, even if the feature is incomplete. Feature flags help where partial states would be user-visible.
How deep should a stack go?
Three to five links is comfortable. Deeper stacks accumulate rebase overhead and coordination cost faster than they add review clarity.
Does this work with squash merging?
Yes, and each link squashes to one trunk commit, which keeps history clean and preserves bisectability — see git bisect guide.
What if a reviewer wants changes to the bottom link?
Amend it and restack. This is the case tooling exists to make painless.
Where to go next
For the branching model, read trunk-based development. For review practice, pull request review culture, and for finding regressions in the resulting history, git bisect guide.