GitHub opened the public preview of stacked pull requests on July 30, rolling the feature out to all repositories over the following days, and the timing is a more interesting story than the feature itself. Stacked pull requests split a large change into an ordered chain of small, focused PRs — each one pointing to the branch below it rather than directly to main — that can be reviewed and tested independently, then merged together with a single action once the whole stack is approved. The workflow pattern isn't new; tools like Phabricator at Meta and the third-party layer Graphite have popularized "stacked diffs" for years among teams that prioritize small, frequent reviews. What's new is that it now lives natively inside GitHub, without an external service, a separate metadata format, or a per-seat license for a third-party tool layered on top of Git.
Why GitHub built this now: the bottleneck moved from writing code to reviewing it
The specific justification GitHub and the developers quoted in its announcement gave for the timing is worth taking seriously rather than treating as generic feature marketing. Andy Merryman, CTO of TED, put it directly in GitHub's changelog: "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." That's a specific and increasingly common pattern in 2026 engineering organizations — AI coding assistants and agents have measurably increased how much code an individual developer can produce in a given period, but human code review capacity hasn't scaled at anything close to the same rate, since review requires the same careful reading and judgment it always has regardless of how the code was produced. The result is exactly what Merryman describes: PRs that keep growing in size because that's simply how much code got written in a sprint, reviewed by a human capacity that hasn't changed, creating a widening gap between code production and code review throughput.
How stacked PRs actually work, mechanically
Each pull request in a stack points to the layer beneath it instead of pointing directly to main, and GitHub displays a "stack map" at the top of every PR in the chain showing where that specific layer sits within the larger change. Reviewers open any individual PR and see only the diff for that layer, rather than the full cumulative change — which is the entire point, since it restores the smaller, focused review unit that large single PRs eliminate. Merging works by layers: merging the topmost PR that's ready to land automatically merges that layer along with every layer beneath it that's still unmerged, in a single operation. If a lower layer changes after upper layers have already been reviewed, those upper layers automatically rebase and retarget against the new base — eliminating what was previously the single biggest practical obstacle to using a stacked-diff workflow manually on GitHub: the tedious, error-prone process of manually rebasing and reopening every dependent branch every time an earlier layer in the chain changed.
The interfaces available, and where each one fits
The feature works across github.com directly, the GitHub CLI via the gh extension install github/gh-stack extension, the GitHub mobile app, and coding agents like GitHub Copilot using the gh-stack skill. That range of interfaces matters because the practical workflow differs meaningfully by use case: reviewing and approving layers works well directly in the browser, with the built-in stack map giving reviewers context without leaving github.com. Creating and reordering a stack, on the other hand, is meaningfully easier from the CLI, where the gh-stack extension automates branching, pushing, and opening a PR for each layer — a typical two-layer workflow looks like creating a branch, committing the first layer's change, running gh stack push, then repeating for the next layer, with each gh stack push opening or updating the PR for that specific layer automatically. The mobile app is positioned specifically for reviewing or commenting on a layer on the go, not for creating a stack from scratch.
Branch protections don't change, and that's a deliberate design choice
A detail worth flagging for any engineering leadership evaluating whether to adopt this workflow: main's branch protections and required checks continue to apply exactly as they did before, regardless of how many layers a stack contains. Stacked pull requests aren't a mechanism for bypassing required reviews or status checks — they change how a large change is organized and reviewed, not what governs whether it's allowed to merge. That's an important distinction for any team concerned that a faster, more automated PR workflow might quietly weaken existing code review or compliance controls; GitHub's design here explicitly preserves the same gate that governed single, monolithic PRs, just applied at the layer level instead of the whole-change level.
The merge queue gap, and what it means for immediate adoption
Merge queue support for stacks is rolling out progressively over the coming weeks rather than being available at the public preview's launch, which is a meaningful limitation for teams that rely heavily on merge queues to manage merge ordering and avoid conflicts in high-velocity repositories. John Resig, creator of jQuery, specifically praised the combination of stacked PRs with merge queue support — "landing 5 stacked PRs directly to a merge queue all at once" — suggesting that once that integration fully lands, the workflow becomes meaningfully more powerful for teams already using merge queues as their primary integration mechanism. Teams evaluating adoption now should factor in that the full workflow, including merge queue integration, isn't complete yet, and plan an initial rollout accordingly rather than assuming day-one feature parity with how stacked diffs work in more mature third-party tools like Graphite.
How this compares to Graphite and other existing stacked-diff tools
Graphite, the most prominent third-party tool built specifically around the stacked-diff workflow on top of GitHub, has spent several years building a business around exactly the problem GitHub is now addressing natively — and teams already paying for Graphite or a similar tool have a genuine decision to make once GitHub's native version matures out of public preview. The core tradeoff is a familiar one in developer tooling: a native platform feature typically wins on integration depth and zero-additional-cost adoption, since it requires no separate account, no additional per-seat billing, and no risk of the underlying platform changing in ways that break a third-party integration layer. A mature third-party tool typically wins, at least initially, on polish, edge-case handling, and features built specifically around power-user stacked-diff workflows that a first public preview from a much larger platform hasn't had years to refine. Teams currently paying for a third-party stacked-diff tool should treat GitHub's native preview as a serious evaluation candidate for future budget cycles, without necessarily migrating immediately while the native feature is still working through public preview limitations like the pending merge queue integration.
Why the AI-coding-agent integration angle deserves separate attention
The detail that stacked pull requests work with coding agents like GitHub Copilot through the gh-stack skill is worth treating as more than a checkbox interoperability feature. As AI coding agents move from generating individual functions or small patches toward autonomously producing entire multi-step features, the natural output of an agentic coding session increasingly resembles exactly the kind of large, multi-layered change that stacked PRs are designed to decompose. An agent capable of building a stack directly — creating the data model layer, then the endpoint layer, then the test layer, each as a separately reviewable PR — produces a fundamentally more reviewable artifact than an agent that dumps its entire multi-step output into a single enormous diff and leaves a human to manually figure out how to break it apart after the fact for review purposes. Engineering teams adopting AI coding agents at scale should specifically evaluate whether their agent tooling supports building stacks natively as part of its output, since that capability determines whether agent-generated code arrives in a reviewable shape by default or requires manual post-processing before a human reviewer can reasonably engage with it.
What engineering teams should actually do with this release
-
If your team has been experiencing exactly the symptom Merryman described — PRs growing larger because AI-assisted development increased per-developer code output faster than review capacity scaled — treat this release as directly relevant infrastructure rather than a nice-to-have workflow experiment. This is specifically the problem the feature was built to address.
-
Pilot the CLI-based workflow with
gh extension install github/gh-stackon a single team or repository before rolling it out broadly, given that this is a public preview rather than a generally available feature, and behavior may still change before it stabilizes. -
If your team relies heavily on merge queues, hold off on full production dependence on stacked PRs until merge queue support for stacks completes its gradual rollout, since the two features working together is where a meaningful part of the workflow's value comes from, based on early adopter feedback.
-
Use this as a prompt to audit your current PR size and review turnaround metrics, independent of whether you adopt stacked PRs specifically. If your organization hasn't measured whether AI-assisted development has meaningfully increased average PR size or review latency, this release is a useful trigger to start tracking it.
Stacked pull requests landing natively in GitHub is a genuinely useful workflow improvement on its own terms, but the more durable signal is what motivated it: a large enough share of engineering organizations are now generating code fast enough with AI assistance that human review, not code production, has become the throughput constraint. Expect more developer tooling investment aimed specifically at review efficiency — rather than code generation speed — as that bottleneck becomes the industry's default engineering constraint through the rest of 2026.