Big Pull Requests don't get reviewed - they get skimmed and "LGTM"-ed, and the data backs it up. SmartBear's study of 2,500 code reviews at Cisco found reviewers' ability to catch defects drops sharply beyond ~400 lines of code, Microsoft Research found the density of useful review comments falls as changes get bigger, and Graphite's analysis of millions of PRs found 50-line changes are ~15% less likely to be reverted than 250-line ones.
Stacked Pull Requests fix this by splitting one big change into a chain of small PRs, where each PR targets the branch below it instead of main. Reviewers see a handful of focused files per PR, and each one gets a real review.
A stacked Pull Request is a PR that targets another PR's branch instead of main. The bottom PR targets main, the second targets the first, and so on. Each PR's diff only shows its own changes, so the reviewer of PR #3 never wades through the code from PR #1 and #2.
Under the hood it's still just base branches - no magic. What changed is that GitHub now detects the chain and gives you native tooling to visualise, rebase, and merge the whole stack.
Note: GitHub's native stacked PR support is in public preview (July 2026) and may change. Before that, teams needed third-party tools like Graphite or spr to get this workflow - they are still worth a look for deep stacks, but for a 3-PR stack the native experience is enough
Stacking shines when one piece of work naturally splits into dependent steps:
One giant PR - feature/reporting touches the schema, 3 API endpoints, and 12 UI components in a single 48-file PR. The reviewer approves it in 4 minutes with one comment: "LGTM"
❌ Figure: Bad example - Large PRs get skimmed - approval without real review
A stack of 3 - PR #1 adds the schema migration, PR #2 (based on #1) adds the endpoints, PR #3 (based on #2) adds the UI. Each PR gets reviewed on its own small diff, and the whole stack lands on main together
✅ Figure: Good example - Small stacked PRs each get a real review
Tip: Keep the stack shallow - 3 or 4 PRs at most. Every extra level multiplies the rebasing and coordination overhead when a lower PR changes
feature/add-greeting off mainfeature/use-greeting from feature/add-greeting (not from main), and open its PR with the base set to feature/add-greetingWhen review feedback changes a lower PR, the branches above it diverge. GitHub flags this on the stack and offers a Rebase stack button, which rebases each branch onto the one below it and force-pushes the result.
Warning: Rebase stack rewrites and force-pushes every branch above the change. Anyone with one of those branches checked out will need to reset their local copy - avoid sharing stack branches with teammates mid-flight
Once the whole stack is approved, click Squash and merge stack to land every PR on main in one action, preserving stack order in the commit history. Don't squash-merge stacked PRs one at a time outside the stack tooling - squashing creates new commit SHAs and leaves the PRs above with a broken base.
Tip: Try the workflow on a throwaway repository first. The stack banner, rebase button, and merge behaviour make much more sense after one 10-minute practice run
One of our Solution Architects, Dan Mackay, went into stacked PRs sceptical and came out a fan. His blog post walks through the whole workflow end to end with screenshots of every step (see link below).
gh stack CLI extension