Stacked PRs Kill the 2,000-Line Review

Native stacked PRs are on GitHub. Break that monster diff into a chain of small reviews — no third-party tools needed.

Dafallah Ibrahim

— 2 min read
Share

GitHub just shipped stacked pull requests in public preview. If you've ever sat on a 2,000-line PR because no one had time to review it, or held a feature branch hostage while waiting on a bottleneck — this is your exit strategy.

Stacked PRs let you break work into a chain of small, focused diffs where each builds on the previous one. You keep coding while earlier PRs are still under review.

Why this matters

Small PRs review faster, catch more bugs, and merge more safely. Every engineering team knows this. The problem was always logistics: if your dashboard depends on your auth refactor, you either wait for auth to merge before touching dashboard code, or you shove everything into one PR and hope.

Stacking kills that false choice. You write auth, immediately start dashboard on top of it, and file two separate PRs. Reviewers see clean diffs. You stay unblocked.

How it works

A stack is a chain of branches where each branch's base is the one below it — not main. When you open a PR for feature/dashboard, you set its base to refactor/auth instead of main. The diff shows only what dashboard adds on top of auth.

This is still plain git underneath. The branches are real, the commits are real, the merge mechanics are the same. The difference is that GitHub now understands the dependency chain between your PRs and can visualize the full stack.

Where this helps

  • Long-running features: Split a sprint's work into five stacked PRs instead of one monster. Each gets reviewed and merged independently.
  • Refactor then feature: Stack the refactor underneath the feature. Reviewers approve the cleanup first, then see exactly what the feature adds on top.
  • Prototype to production: Stack experimental code on a branch you might throw away. If it works, merge up. If not, drop the whole stack.

Watch out

This is public preview, not GA. Expect rough edges in the UI.

Rebase conflicts are the real pain point. If the bottom PR gets review feedback and you rewrite history — squash, force-push — the branches above it may need manual rebasing. The more PRs in your stack, the worse this gets.

Keep stacks shallow. Three levels is the sweet spot. Deeper stacks look elegant in theory but become a merge-order nightmare when reviewers request changes on multiple levels at once.

Stacked PRs also demand reviewer discipline. If your team treats the stack as one giant PR, you've gained nothing. Each level needs its own focused review.

Try it yourself

The git mechanics behind any stack — GitHub native or otherwise:

# Start from main
git checkout main && git pull

# First PR: refactor auth module
git checkout -b refactor/auth
# ... make changes, commit
git push -u origin refactor/auth

# Second PR: dashboard depends on auth
git checkout -b feature/dashboard
# ... make changes, commit
git push -u origin feature/dashboard

# Third PR: settings depends on dashboard
git checkout -b feature/settings
# ... make changes, commit
git push -u origin feature/settings

Now open three PRs. Set each base to the branch below it: feature/dashboard targets refactor/auth, feature/settings targets feature/dashboard. GitHub's stacked PR UI now handles this relationship natively.

TL;DR

  • What changed: GitHub shipped native stacked PRs in public preview — no more Graphite or manual branch juggling required.
  • Why it matters: You can split work into small, reviewable diffs without blocking on each merge.
  • What to try today: Create a two-level stack on your next feature. Refactor underneath, feature on top, file both as separate PRs.

Read more