GitHub Stacked PRs: How to Use Them, and When to Skip Them

A few weeks ago, I spent three days trying to review a single pull request. It was a backend change with a database migration, a new API endpoint, and a refactor of the existing service layer, all bundled into one diff of over a thousand lines. Every time I opened it, I lost my place. By the time I finished, the branch had drifted from main and the author had to rebase, which changed half the diff again.

This is not a story about a bad team. This is the default state of code review at most companies. And it is getting worse, because the tools that generate code now produce changes faster than reviewers can read them.

On July 30, 2026, GitHub released stacked pull requests in public preview. Until now, this workflow lived almost entirely in third-party tools. Here is what changes now that the most widely used code host in the world ships it natively, how to try it, and where I would still avoid it.

The problem: one change, one giant PR

Most teams review the same way they did ten years ago. You branch from main, make all your changes, and open one PR when you are done. If the feature is large, the PR is large, and everything downstream suffers.

• Review latency. A 1,000-line diff takes days to review properly. Reviewers open it, get interrupted, and come back with no memory of where they were.
• Blocked work. Nobody wants to review a second PR while the first is still open, so developers either wait or pile unrelated changes onto the same branch.
• Conflict churn. The longer a branch lives, the more it drifts from main. Every rebase invalidates part of the review.

The traditional workarounds do not help. You can split the work into multiple PRs, but dependent changes cannot be reviewed independently. You can squash everything into one commit, but that hides the structure of the change. Or you can open one giant PR and accept that review quality will drop.

This is the gap stacked PRs were built to fill.

What stacked PRs actually are

A stack is an ordered series of pull requests, where each PR represents one focused layer of a larger change and targets the PR below it instead of main.

Imagine a feature that needs a schema change first, then an API layer, then a frontend update. In a stack, that is three PRs: PR 1 changes the schema, PR 2 builds on PR 1, PR 3 builds on PR 2. Each PR contains only its own diff, so each can be reviewed, tested, and approved on its own. The dependency order is explicit, and the platform understands it.

The concept is not new. Phabricator teams used stacked diffs for a decade, and Google and Meta have internal equivalents. What is new is that the most widely used forge in the world now ships it natively.

What GitHub shipped on July 30, 2026

According to the official changelog, stacked pull requests are rolling out in public preview to all repositories over the coming days. The description is straightforward: an ordered series of pull requests that each represent focused layers of your change, where you can independently review and check each PR, then merge everything together in one click.

The key details from the announcement:

• CLI extension. You install it with gh extension install github/gh-stack and can create your first stack in under a minute.
• Multiple entry points. Stacks can be created from the terminal, from github.com, from the GitHub mobile app, or from a coding agent such as GitHub Copilot using the gh-stack skill.
• Layer-by-layer review. Opening any PR in a stack shows only that layer's diff. A stack map at the top of the PR shows how the change you are reviewing fits into the larger work, and teammates can review different layers in parallel.
• One-click merge. Merging the latest ready PR lands it and every unmerged layer below it in a single operation. You can also merge only the lower layers, and the PRs above stay open, automatically rebasing and retargeting.
• Existing protections still apply. Branch protections and required checks keep governing what reaches main, and merge queue support is rolling out progressively over the coming weeks.

The announcement includes quotes from teams that piloted the feature. Tim Neutkens, lead of Next.js at Vercel, said the team has used GitHub stacked PRs for Next.js for months, and it has made it easier to review PRs by introducing smaller individual changes. Andy Merryman, CTO of TED, made the AI connection explicit: AI has made TED's developers dramatically more productive, but that created a new bottleneck, because PRs were growing large enough that reviewers were struggling. In his words: "By breaking large changes into small, dependency-ordered pieces, review happens in smaller logical chunks, not just faster PR reviews, but more accurate ones."

The AI point matters. If the models are writing more of the code, the human bottleneck has shifted from writing to reviewing.

Why native support changes things

Before this release, teams that wanted stacked workflows had to build them on third-party tools. Graphite is a commercial option that wraps the workflow in its own UI, and git-spice is an open source alternative that stays close to plain git. Hacker News regulars in the launch thread described the pre-GitHub experience well: after using Graphite, it is hard to go back to a stack-less GitHub, and git-spice was recommended repeatedly as a tool that does exactly what you want and no more.

But third-party stacking always had friction. You installed another tool, another UI, maybe another subscription, and your teammates had to adopt it too. Comments from the thread describe the manual alternative: telling reviewers "this PR depends on #123, I will retarget when that merges," and keeping branches in sync by hand.

Now the workflow lives on the platform every team already uses. The launch thread reaction from Steve Klabnik, a long-time Rust community member, called it one of the biggest changes to hit GitHub in many years. Commenters also noted that GitLab released similar stacked merge-request support recently. My reading of both launches is that the forges are responding to the same pressure: AI-generated diffs need to be broken into human-reviewable chunks.

There are also signs the ecosystem is taking it seriously as a platform feature. GitHub's team confirmed a public REST API for all stack operations, and Trunk's merge queue added support for GitHub stacks on launch day, working with GitHub's team directly.

How to try it this week

The following walkthrough is based on the official changelog and the launch thread. I have used stacked workflows through git-spice in my own projects, but I have not run GitHub's preview end to end yet, so treat the exact steps as the announcement describes them, not as my hands-on report.

Step 1: Install the extension.

gh extension install github/gh-stack

Step 2: Build your first stack. Start with a branch and a PR for your first change, exactly as you do today. Then create a new branch on top of it for the next layer, and open another PR that targets the layer below, not main. Repeat for each layer.

Step 3: Review layer by layer. Open any PR in the stack and you see only that layer's diff, with the stack map showing where it sits in the whole change. Different reviewers can take different layers at the same time, and lower layers can merge while upper layers are still being reviewed.

Step 4: Merge what is ready. To land everything, merge the topmost ready PR, which also lands every unmerged layer below it. To land part of the work, merge the lower layers individually; the PRs above stay open and retarget automatically.

Step 5: Watch the preview edges. This is a public preview, and the thread documents real rough edges. Merging an entire stack was broken in several cases early on, and squash merging with required reviews asks for re-approval on every layer. GitHub's team responded in the thread that fixes for squash merging were rolling out, and the broader PR UI is being revamped. Cross-fork stacks are not supported yet, which matters for open source contributions, though the team said support is coming.

If you hit a preview bug, the discussion threads around gh-stack are active and the GitHub team is answering there directly.

When to skip stacked PRs

Native support does not mean every team should adopt it. Stacked PRs solve a specific problem: large, ordered changes that must be reviewed in pieces. If that is not your situation, the overhead is not worth it.

• You already ship small PRs. If your team reviews 50-line diffs within hours, stacking adds ceremony without adding value.
• You are the only developer. Managing a stack of branches is overhead with no reviewer to benefit from it.
• Your team never rebases. Stacks depend on keeping branches in sync with their parents. A team that avoids rebasing will fight the workflow constantly.
• You run a trunk-based flow with tiny merges. If work lands on main continuously in small increments, there is nothing to stack.
• You maintain release branches. Hotfixes that must land in a specific order across branches fit stacks poorly, because stacks assume a linear dependency chain.
• You accept contributions from forks. Cross-fork stacks are not supported yet, so public open source repos should wait.

On the flip side, the conditions where stacks earn their keep are concrete: PRs that regularly exceed a few hundred lines, work that builds on other unmerged work, AI agents generating large diffs for you to review, and teams that ship from long-lived feature branches.

What I would do differently

My team runs the same review pipeline as everyone else, and the last year of AI-assisted development has made the pattern obvious: the diff generation got faster, the review did not. Stacked PRs are the first workflow change that actually attacks that asymmetry, by giving every logical unit of a change its own review thread, its own CI run, and its own merge decision.

If I were rolling this out tomorrow, I would start small. Two or three layers, not ten. A stack of ten PRs is a new kind of monster, and several commenters in the thread predict exactly that failure mode. I would also keep branch protections on every layer, because the one-click merge makes it easy to land layers that only got a shallow review.

The deeper change is cultural. A PR stops meaning "all of my work" and starts meaning "one focused, reviewable unit of work." That is a better definition, but it takes discipline to maintain. The stack does not split your work for you; you still have to design the layers.

A quick checklist for your first stack

• [ ] Install gh-stack and confirm your GitHub CLI is up to date
• [ ] Pick a feature that splits naturally into 2 to 3 dependent layers
• [ ] Open the bottom layer first and get its review moving early
• [ ] Use the stack map to explain to reviewers which layer you want reviewed
• [ ] Merge bottom-up, and only merge layers that are green and approved

Have you tried stacked PRs yet, or are you still shipping thousand-line diffs? I would like to hear how the preview holds up in a real review queue, especially if you have hit the squash-merge edges.

I write about Java, Spring Boot, and AI every week, and this launch matters for anyone building with AI agents, because the review queue is the new bottleneck. Subscribe, it is free.