Stacked PRs Are Here: Finally, a Workflow That Matches How Your Brain Actually Works

The Monster PR Problem Nobody Wants to Talk About

For years, we’ve been told to “make smaller PRs.” It’s the golden rule of code review. Yet every team with a monorepo larger than a few hundred thousand lines knows the dirty secret: small PRs are structurally impossible when you’re shipping anything meaningful.

A typical feature touches 15 files across 3 microservices. You could split it into 5 PRs, but then you’re managing interdependencies across branches like some kind of medieval cartographer. Each PR has to be rebased against the others. Merge conflicts cascade. Reviewers can’t validate the full picture. By the time everything lands, you’ve spent more time on branch management than on the actual feature.

The result? Engineers cheat. They squash everything into one massive PR because it’s the path of least resistance. And that 90-minute review we mentioned earlier? It becomes a skim-and-approve ritual that ships bugs into production.

What Stacked PRs Actually Do (And Why It Matters)

The official definition sounds deceptively simple. As the GitHub documentation states, stacked pull requests “break large changes into small, reviewable, stacked pull requests.” But the mechanics are where the magic lives.

A stack is an ordered series of PRs where each PR targets the branch of the PR below it, forming a dependency chain that ultimately resolves to main. Here’s how it works in practice:

PR #1: Add database migration (targets main)
PR #2: Add data access layer (targets PR #1's branch)
PR #3: Add API endpoints (targets PR #2's branch)
PR #4: Add frontend components (targets PR #3's branch)

Each PR in this chain contains only the diff for its specific layer. Reviewers can examine PR #2 without wading through frontend code. CI runs independently on each layer. And when everything’s approved, you merge the top PR and GitHub automatically cascades the entire stack into main in one operation.

Getting started takes under a minute:

gh extension install github/gh-stack

That’s it. The CLI extension handles the branching logic, rebasing, and merge orchestration that previously required custom scripts or third-party tools like Graphite.

The Real-World Impact: A Decade-Old Codebase Modernized in Hours

The most convincing case study comes from Cassidy Williams, GitHub’s senior director of developer advocacy, who documented her experience modernizing a personal project that had been rotting since 2014. Her repo was running React 15 (released in 2016), Less for CSS preprocessing, and a version of react-bootstrap that should be in a museum.

Cassidy’s first attempt to modernize this codebase before AI tools had failed. She had tried and given up. The interdependencies were too tangled. The changes too large. The juice not worth the squeeze.

When she tried again using the GitHub Copilot app with stacked sessions, the workflow looked like this:

1. Initial session: Copilot generated a frontend modernization plan
2. Discovery: She realized an old dev branch existed with partial updates, her current deployment depended on it
3. Pivot: Instead of scrapping everything, Copilot closed the first PR, created a new session targeting the correct branch, and ported her styling decisions
4. Scope management: During testing, she discovered react-bootstrap was generating console warnings. Instead of bloating her current PR, she triggered a new stacked session
5. Automatic chaining: The Copilot app created a stacked PR, a new branch off her current work, with its own PR that would merge into dev only after the first one

As Cassidy put it: “The GitHub Copilot app made a pull request for all of my current changes off dev, made a ‘stacked session’ for react-bootstrap removal, and made a stacked pull request following my existing work. THIS WAS SO COOL.”

This isn’t just a developer experience improvement. It’s a fundamental change in how we can think about change management in large codebases.

The Data That Proves We Needed This

The productivity numbers around AI-assisted development have been eye-popping but misleading. An NBER study tracking over 100,000 GitHub developers found that weekly lines of code changed shot up by 650% depending on the workflow. But releases only increased by 30%. That’s the AI productivity paradox in action.

The bottleneck shifted from writing code to reviewing it. AI made developers dramatically more productive, but that created a new problem: PRs were growing large enough that reviewers were struggling.

Andy Merryman, CTO of TED, articulated this precisely: “AI has made TED’s developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling. Stacked PRs help to solve that.”

The core insight is that the growing gap between code generation speed and review throughput can’t be solved by simply asking developers to write less code. The solution requires changing the structure of how work is presented for review.

Parallel Review at Scale

One of the most underrated features of stacked PRs is that they enable genuine parallel review. Instead of one reviewer slogging through a 40-file PR while everyone else waits, multiple reviewers can grab different layers of the stack simultaneously.

The PR UI now includes a stack map at the top that shows how each layer fits into the larger work. Open any PR in the stack and you see only the diff for that specific layer. The context around where it sits in the broader change is always available but never forced on you.

John Resig, creator of jQuery, tested the preview and called it “incredible”: “Landing 5 stacked PRs directly to a merge queue all at once! A+++! This removes so much friction.”

The merge queue integration is particularly important. When the top PR is ready, GitHub merges it and every unmerged layer below it in one operation. Merge one or more lower layers, and the PRs above stay open, automatically rebasing and retargeting. Your existing branch protections and required checks still govern what reaches main.

The Cultural Shift This Demands

Stacked PRs aren’t a silver bullet. They require teams to think differently about how they decompose work. A feature that would have been one monolithic PR now needs to be consciously split into logical layers: database changes, data access, API, frontend.

This is harder than it sounds. It requires discipline to resist the temptation to include “just one more small change” in each layer. It requires reviewers to trust that the stack will merge correctly, a trust that must be earned through consistent behavior.

There’s also the question of how strict PR review cultures create bottlenecks. If your team already struggles with review latency, adding more PRs (even smaller ones) won’t help unless you also address the cultural factors. Stacked PRs enable a different workflow, but they don’t enforce it.

What This Means for Monorepo Teams

For organizations running monorepos, stacked PRs address a pain point that’s been festering for years. Monorepos offer undeniable benefits, simplified dependency management, atomic commits, unified CI/CD, but they’ve historically made it harder to ship independent changes in parallel.

The branching model has been the bottleneck. With stacked PRs, teams can work on multiple layers of a feature simultaneously, each with its own review cycle, CI pipeline, and merge timeline. The 50-file “atomic” commit that tries to capture an entire feature in one shot becomes unnecessary. You can ship the database migration, get it reviewed, deploy it, and then layer the API changes on top.

This is particularly valuable for infrastructure changes where ordering matters. A schema change must land before the ORM layer. The ORM layer must land before the service layer. Stacked PRs make this dependency chain explicit and manageable rather than a source of merge conflicts.

Getting Started: The Practical Path

If you want to experiment with stacked PRs, the path is straightforward:

1. Install the CLI extension: gh extension install github/gh-stack
2. Create your first branch and PR normally
3. Instead of pushing more commits to that branch, create a new branch off it
4. Create a PR from the new branch, GitHub automatically detects the stacking relationship

The CLI handles the tedious parts. If you rebase the base branch, the stacked PRs automatically rebase. If you merge a lower layer, the higher layers retarget. The cognitive load of managing the chain is pushed onto the tooling, where it belongs.

For teams using the GitHub Copilot app, the integration is even tighter. The Copilot app can create stacked sessions automatically, as Cassidy demonstrated. When you ask it to split work into multiple PRs, it handles the branching, session creation, and dependency tracking.

The Verdict: Necessary Evolution, Not Just a Nice Feature

Stacked PRs aren’t a gimmick. They’re a necessary evolution of the code review workflow for an era where AI generates code faster than humans can review it. The old model, one branch, one PR, one review cycle, simply doesn’t scale when developers are producing 7x more code per unit time.

The engineering leaders at Vercel, TED, and WHOOP have been testing this internally for months. Tim Neutkens, Next.js lead at Vercel: “It has helped us introduce smaller individual changes while shipping larger features, making it easier to review PRs.”

Mayank Saini, connectivity engineer at WHOOP: “A big change used to mean one giant PR nobody wanted to review. Now it’s a stack of small ones reviewers can actually follow, and the whole stack merges in one shot.”

The most telling line from the WHOOP engineer: “It stopped feeling like a tool on top of GitHub and started feeling like GitHub.”

That’s the goal, isn’t it? Not a new tool bolted onto your workflow, but a workflow that finally works like you always wished it would. Stacked PRs are in public preview now, rolling out to all repositories over the coming days. Worth your attention.