Stacked pull requests are a chain of dependent PRs where each one builds on the branch of the previous. A large change is split into small steps, reviewed independently, and merged from the bottom of the stack up.
The short answer: What are stacked pull requests solving? The conflict between how developers work and how reviewers read. Big features are built in sequence, but nobody reviews a 2,000-line diff well. A stack keeps the author moving on step three while steps one and two are under review, and every reviewer only ever sees a small, coherent piece.
How do stacked pull requests work?
Instead of one feature branch targeting main, you cut a chain: branch A off main, branch B off A, branch C off B. Each branch becomes a pull request whose base is the branch below it, so every diff shows only that step. Say you are adding an export feature: PR one adds the data model, PR two the API endpoint on top of it, PR three the UI on top of that. Review and merge run bottom up. PR one merges into main first; PR two is then retargeted onto main and merged; PR three follows. When a lower PR changes in response to review, the branches above it are rebased so the stack stays consistent. That rebase cascade is the tax the whole workflow lives with, and we will come back to it.
What are stacked pull requests for?
Small diffs get better reviews; that is one of the most consistent findings in review practice, and it is the core argument in our guide to how big a pull request should be. The problem is that real features are often irreducibly large. Without a stack, the author faces a bad choice: ship one huge PR that gets skimmed, or sit blocked waiting for each small PR to merge before starting the next. Stacking removes the wait. The author keeps building on their own unmerged work while review proceeds underneath, and each reviewer gets a diff sized for actual reading. It is the same instinct behind atomic commits, promoted from commit granularity to PR granularity.
What tools support stacking?
GitHub has begun building stacks in natively: as InfoWorld reported, GitHub added stacked pull requests specifically to speed up review of complex changes. Since 30 July 2026 it has been in public preview for every repository, no waitlist, though still labelled subject to change; we track the details in our deeper look at GitHub stacked pull requests. In the meantime the workflow is well served by third-party tools (Graphite is the best known) that automate the branch bookkeeping: creating the chain, restacking after changes, and retargeting PRs as lower ones merge. And plain GitHub works too, manually, for shallow stacks. The broader tool landscape is covered in our roundup of GitHub PR review alternatives.
What do stacks cost?
The honest ledger has three entries. First, rebase overhead: every change to a lower PR ripples upward, and without tooling you pay that in manual rebases and force-pushes. Second, review coordination: reviewers of PR three are looking at code built on unreviewed foundations, and feedback on PR one can invalidate work above it. Third, platform friction: force-pushing rebased branches can confuse review state, resetting what reviewers had already read. None of this is disqualifying, but it means stacks are a deliberate practice, not a free upgrade. Use them when the work is genuinely large and sequential, keep each layer independently understandable, and let the bottom of the stack merge fast. A stack whose base PR sits unreviewed for a week is just a big PR with extra steps.
Frequently asked questions
Can you create stacked pull requests on GitHub without extra tools?
Yes. Open each branch against the one below it instead of against main, then merge from the bottom and retarget as you go. It works, but keeping the stack rebased by hand gets tedious past two or three PRs, which is why dedicated stacking tools exist.
How is a stacked pull request different from a normal branch with many commits?
A multi-commit branch still lands as one pull request with one review and one merge. A stack splits the same work into separate PRs, each with its own reviewer, discussion, CI run, and merge, so review happens in small units while the work stays connected.
When are stacked pull requests not worth it?
When the change is already small, or when the pieces are truly independent and could just be separate unrelated PRs. Stacks pay off when work is large and sequential. If your team rarely reviews within a day, the coordination cost of a stack can exceed its benefit.
Top comments (0)