Stacked PRs: The Complete Guide

What Are Stacked Pull Requests?

Stacked pull requests (also called stacked diffs, dependent PRs, or chained PRs) are a development workflow where a large feature or change is broken into multiple smaller, sequential pull requests that build on top of each other. Each PR in the stack contains a focused, logically coherent change, and each depends on the one before it in the chain.

Instead of one massive 2,000-line pull request that takes days to review, you create a chain of four or five 200-line PRs that reviewers can understand, approve, and merge independently. The first PR targets main, the second targets the first PR's branch, the third targets the second, and so on — forming a "stack" of changes.

Consider building an e-commerce checkout feature. Rather than one giant PR, you'd stack it like this:

This workflow was pioneered at Meta (Facebook) using their internal tool Phabricator, where it's called "stacked diffs." Google uses a similar approach through their internal tools. The concept entered the broader GitHub ecosystem through tools like ghstack and was popularized by Graphite, founded by former Meta engineers who wanted to bring the stacked diffs workflow to GitHub.

Why Use Stacked Pull Requests?

Research analyzing 1.5 million pull requests from top engineering teams found that PRs with 200-400 lines have 40% fewer defects than larger ones, and small PRs (<200 lines) get approved 3x faster. Each additional 100 lines increases review time by 25 minutes. At 1,000+ lines, defect detection drops by 70%.

Stacked PRs vs Large Pull Requests

Here's a side-by-side comparison of the traditional "one big PR" workflow versus stacked pull requests:

How Stacked PRs Work on GitHub

GitHub does not have built-in support for stacked PRs, but the workflow works natively with standard Git branching. The key insight is simple: each PR targets the previous branch as its base, not main.

1. PR #1 branches from main and targets main — this is your normal PR.
2. PR #2 branches from PR #1's branch and targets PR #1's branch as its base. The diff only shows changes introduced in PR #2.
3. PR #3 branches from PR #2's branch and targets PR #2. And so on.
4. Merging happens bottom-to-top. Merge PR #1 into main first. GitHub automatically retargets PR #2 to main. Merge PR #2, and PR #3 retargets. Repeat.

Step-by-Step: Creating a Stack of Pull Requests

Let's walk through creating a stack of three PRs for an e-commerce checkout feature, using plain Git (no extra tools).

git checkout main && git pull
git checkout -b feature/checkout-01-schema

# Make your database schema changes
git add -A && git commit -m "Add checkout schema"
git push -u origin feature/checkout-01-schema

# Open PR in GitHub → base: main

Handling Review Feedback & Rebases

The trickiest part of stacked PRs is when a reviewer requests changes to an earlier PR in the stack. Every change to a lower branch must be propagated to all branches above it. Here's how to handle it:

Manual rebase (works with any Git version)

# 1. Fix the issue on the base branch
git checkout feature/checkout-01-schema
# Make changes, commit, push
git add -A && git commit -m "Address review feedback"
git push origin feature/checkout-01-schema

# 2. Rebase each dependent branch, one by one
git checkout feature/checkout-02-api
git rebase feature/checkout-01-schema
git push --force-with-lease origin feature/checkout-02-api

git checkout feature/checkout-03-ui
git rebase feature/checkout-02-api
git push --force-with-lease origin feature/checkout-03-ui

Using --update-refs (Git 2.38+, recommended)

Git 2.38 introduced --update-refs, which automatically updates all intermediate branches during a rebase. This is a game-changer for stacked PRs — one command replaces the entire manual cascade.

# Enable globally (do this once)
git config --global rebase.updateRefs true

# Now rebase the entire stack from the top branch
git checkout feature/checkout-03-ui
git rebase main --update-refs

# All intermediate branches are automatically updated!
# Force-push all branches at once
git push --force-with-lease origin \
  feature/checkout-01-schema \
  feature/checkout-02-api \
  feature/checkout-03-ui

Using Graphite (automatic)

With Graphite, rebasing is fully automatic. When you modify a branch, all children are restacked in a single command:

# Make changes on any branch in the stack
gt modify -a    # stage all changes and auto-restack children

# Push the entire stack
gt submit --stack

Best Tools for Stacked Pull Requests

While you can manage stacked PRs with plain Git, tooling dramatically reduces friction. Here are the most popular options, from built-in Git features to full commercial platforms.

gt create -am "message"
gt modify -a
gt submit --stack
gt log short

git config --global rebase.updateRefs true
git rebase main --update-refs

ghstack
ghstack checkout PR_URL
ghstack land PR_URL

stack-pr view
stack-pr submit
stack-pr land

av stack branch <name>
av stack sync
av stack tree

git sl
git amend
git next / git prev
git sync

Best Practices for Stacked Pull Requests

For PR authors

For reviewers

For teams

• Agree on PR size limits. Set a team standard of <200 LOC and <24-hour review turnaround.
• Flag large PRs automatically. Set up CI automations to flag PRs over 250 lines or 25 files and encourage splitting.
• Enable "Automatically delete head branches" in GitHub settings to simplify stack management after merges.
• Consider disabling "dismiss stale approvals" to avoid re-review cascades when stacks are rebased.
• Use a stack-aware merge queue. GitHub's native merge queue doesn't handle dependent PR ordering. Use Graphite, Aviator, or Mergify for stack-aware merging.

Staying on Top of Stacked Pull Requests

Stacked PRs multiply the number of open pull requests your team is managing at any given time. A feature that would have been one PR is now three or five — each needing review, each passing through CI, each getting merged in order. That's a lot of activity to track.

GitHub's built-in notification system (email + bell icon) was already noisy with single PRs. With stacked workflows, it becomes overwhelming. The signal-to-noise ratio drops, and critical events get buried — an approval on PR #1 (which unblocks the rest of the stack) looks the same as a routine comment.

For teams that live in Slack, a dedicated GitHub-to-Slack integration makes stacked PR workflows dramatically more manageable. Instead of polling GitHub, you get real-time alerts in the channels where your team already communicates: PullNotifier sends instant Slack notifications for new PRs, review requests, approvals, CI status changes, and merges — so your team knows the moment a PR in the stack is unblocked and ready for the next review or merge.

This is especially valuable for stacked workflows where merge order matters. When PR #1 gets approved, the reviewer of PR #2 needs to know immediately — not whenever they happen to check GitHub.

Frequently Asked Questions