What are stacked pull requests? Dependent PRs, reviewed small, merged bottom up
Othman Shareef · October 16, 2026 · 5 min read · Code Review Glossary
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.
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.