What Are Stacked Diffs? Stacked PRs Explained for 2026

What are stacked diffs?

Stacked diffs, also called stacked PRs, are a workflow where one large change is split into a chain of small, dependent pull requests that build on top of one another. Each PR captures a single logical step, gets reviewed on its own, and the next PR branches off it - so you keep moving forward while earlier changes are still in review.

The idea comes from Meta, Google, and the Mercurial and Phabricator world, where “one change, one small diff” has been the norm for years. It is only recently that tooling brought the same experience to Git and GitHub, and teams that adopt it consistently report faster reviews and less time blocked. If you want the one-line reference, see our stacked PRs glossary entry - this guide covers the how and the why.

The problem stacked diffs solve

Picture a normal feature branch. You are building a new billing module. It touches a database migration, a data-access layer, a service layer, an API endpoint, and a UI component. In the standard workflow, all of that lands in one pull request. Now you wait a day for review. When feedback finally arrives, it is spread across 900 lines, the reviewer admits they skimmed the middle, and you have been sitting idle - or worse, you started a second feature on top of unreviewed code and now everything is entangled.

This is the core tension of trunk-based development with large PRs: big PRs get worse reviews and block their authors. Research on review quality is consistent - reviewer effectiveness drops sharply once a diff exceeds a few hundred lines, a point we cover in depth in pull request size best practices. Yet real features are large. Stacked diffs resolve the contradiction by decoupling the size of the feature from the size of each review.

How the stacked workflow works

Instead of one branch, you build a ladder of them. For the billing example:

1. PR 1 - migration. Just the database migration. Small, easy to review, merges fast.
2. PR 2 - data layer. Branches off PR 1. Adds the repository methods.
3. PR 3 - service layer. Branches off PR 2. Business logic.
4. PR 4 - API endpoint. Branches off PR 3.
5. PR 5 - UI. Branches off PR 4.

Each PR is a small, self-contained diff a reviewer can fully understand in a few minutes. Crucially, you do not wait. The moment PR 1 is up for review, you start PR 2. By the time a reviewer looks at PR 1, you might already be on PR 4.

When PR 1 gets feedback and you amend it, everything above it needs to be restacked - rebased onto the new version of PR 1. When PR 1 merges to main, PRs 2 through 5 must be rebased onto main. Doing this by hand across a five-deep stack is exactly the kind of fiddly, error-prone git surgery nobody wants to do. This is the whole reason stacked-diff tooling exists: to make restacking automatic.

Why stacked diffs speed up review

The benefits compound:

• Smaller diffs get genuinely reviewed. A 120-line PR gets real scrutiny; a 900-line PR gets a rubber stamp. Splitting the feature means every part actually gets looked at.
• Authors are never blocked. Review latency stops being idle time. You are always working on the next layer while earlier ones are in flight.
• Reviewers see intent. Each PR is one logical step with a clear purpose, so reviewers understand why a change exists, not just what it does.
• Bugs are localized. When something breaks, it is traceable to a single small PR, not buried in a monolithic merge.
• Faster, safer merges. Small independent changes merge quickly and interact less, which reduces the merge-skew risk a merge queue has to guard against.

Graphite’s own data from customer deployments points the same way: Shopify reported 33 percent more PRs merged per developer, and Asana engineers saved around 7 hours per week each after adopting the stacked workflow (source: Graphite tool page). Your mileage varies, but the direction is consistent - smaller units of change move faster through review.

The tooling that makes it practical

You can build a stack with raw git branches, but you will spend your life rebasing. These tools automate it.

Graphite is the most complete stacked-diff platform. Its CLI (gt) creates stacks with commands like gt create and submits them with gt submit, tracking the dependencies between branches and automatically restacking the whole chain when a lower PR changes or merges. It layers a web dashboard, a stack-aware merge queue, and an AI reviewer on top. The stacked-PR CLI is available on Graphite’s free tier; the merge queue and unlimited AI review sit on the Team plan at $40 per user per month. Graphite is GitHub-only, and the workflow has a genuine learning curve, so budget a couple of weeks for the mental model to click.

git spr and Sapling are lighter-weight, open-source options. git spr is a command-line tool that maps a stack of commits to a set of GitHub pull requests and updates them together. Sapling, open-sourced by Meta, brings the same stacked workflow Meta engineers use internally to a Git-compatible source control experience. Both are free and a good fit for teams that want the workflow without adopting a full platform.

Whichever tool you pick, stacked diffs pair well with automated review. An AI reviewer that understands full-repo context - such as Greptile, which indexes the whole codebase rather than just the diff - is useful in a stack because it can reason about how a small change relates to the layers below it. See what AI code review is for how that first-pass review fits the flow.

Common pitfalls

Stacked diffs are powerful but not free of sharp edges:

• Stacks that grow too tall. A ten-deep stack becomes its own coordination problem. Keep stacks shallow and merge the bottom promptly.
• Reviewers who do not understand the flow. If your reviewers are not used to stacks, they may not know to review the bottom first. Set the norm explicitly.
• Manual rebasing. If you try to run stacks without tooling, restacking will eventually cause a painful mistake. Use a tool.
• Platform lock-in. The best-integrated tool, Graphite, is GitHub-only. Teams on GitLab or Bitbucket have fewer polished options.

The takeaway: stacked diffs let feature size and review size vary independently - but only if you let a tool handle the restacking for you.

Conclusion

Stacked diffs solve the oldest tension in code review: real features are large, but large PRs get poor reviews and block their authors. By splitting a feature into a chain of small, dependent pull requests, you get fast, thorough reviews on every piece while never waiting idle. The workflow only works when restacking is automated, which is what Graphite, git spr, and Sapling provide. Combined with small PRs, a merge queue, and early AI review, stacked diffs are one of the highest-leverage changes a fast-moving team can make to its shipping velocity.

Further reading

• What Is a Merge Queue? How It Stops Broken Main Branches
• Pull Request Size Best Practices - The Case for Small PRs
• What Is AI Code Review? How It Works and Benefits
• Stacked PRs - glossary definition

Further Reading

• DORA Metrics Explained - The 4 Keys and How Code Review Drives Them (2026)