GitHub Ships Stacked Pull Requests and One Limitation Decides Whether Your Team Can Actually Use Them

What Shipped

GitHub moved stacked pull requests into public preview on July 30, 2026, rolling out to all repositories over the following days. Merge queue support is arriving more slowly, described as progressive over the coming weeks.

A stack is two or more dependent pull requests in one repository. The bottom one targets your trunk, usually main, and every layer above it targets the branch below. Each pull request shows only its own diff, so a reviewer sees one focused change instead of a wall of unrelated edits. The rule that governs the whole arrangement is simple: if code in one layer depends on code in another, the dependency has to be in the same branch or a lower one.

You drive it from the terminal with a CLI extension:

gh extension install github/gh-stack

Stacks are also visible on github.com, in the mobile app, and to coding agents through a gh-stack skill. GitHub Desktop is the exception and does not support them.

The Problem It Actually Solves

The pitch is usually framed as reviewability, and that is true but incomplete. The sharper benefit is what happens when a review finds something.

A large change submitted as one pull request has a single fate. One objection anywhere in it blocks the entire thing, including the parts nobody disputes. If the review cycle takes a day and there are four rounds, the uncontroversial 90 percent of the work waits four days for the contested 10 percent. Anyone who has watched a refactor sit behind a disagreement about one function knows the shape of this.

Split into layers, each layer has its own fate. The parts that pass land. The contested layer stays open and keeps being argued about while everything below it is already in production. That is a different economics of review, and it is the reason teams adopted this pattern with external tooling long before GitHub supported it.

How Merging Works

Pull requests must merge from the bottom up. You cannot land layer three while layers one and two are still open, which follows from the branch targeting rather than being an arbitrary rule.

Beyond that you have room to move. Merge the whole stack at once, or merge the latest ready pull request to land it and every unmerged layer beneath it in a single operation. You can also merge only the lower layers and leave the rest open, in which case the pull requests above stay open and automatically rebase and retarget themselves. That automatic cascade is the part that used to be manual and error prone, and it is the main thing GitHub has taken off your hands.

Commit, squash and rebase merges are all supported, and the feature is merge queue aware. Existing branch protections and required checks still govern what reaches your trunk, so this does not open a side door around your rules.

The Limitation That Matters

The announcement does not dwell on constraints. The documentation does, and one of them decides applicability outright:

Stacked pull requests require all branches to be in the same repository. Cross-fork stacks are not supported.

That single sentence removes the entire fork based contribution model. Open source projects, and any company where contributors work from forks rather than branches on the main repository, cannot use this. The feature is built for teams pushing branches to a shared repository, which is most private product development and almost no public project.

Two smaller ones worth knowing before you commit to it. GitHub Desktop is not supported, so anyone on your team who lives in that GUI is back to the command line or the web. And if you merge through the API rather than the interface, GitHub states you will need to move to a new merge API built for stacks, which is real work if you have automation around merging.

It is also a public preview and explicitly subject to change. That is a reasonable place to run an internal team workflow and a poor place to hang a release process you cannot afford to rewrite.

If You Are Not On GitHub

Plenty of teams are not, and this is worth saying plainly rather than pretending the feature is universal. The pattern itself is older than GitHub's support for it, and nothing stops you from building a stack by hand: branch from branch, open the pull requests in order, and rebase the chain yourself when a lower layer changes. What GitHub has automated is the tedious and failure prone half of that, the cascading rebase and retarget.

GitLab has dependency relationships between merge requests, but not the automatic rebase cascade, so the manual work stays with you. Graphite, which Cursor acquired in December 2025, built its product on exactly this workflow and remains an option for teams that want it without changing forge.

The honest read is that GitHub has absorbed a third party product category into the platform, for free, for anyone already on GitHub and not working from forks. That is good for those teams and awkward for the tools that got there first.

What We Would Actually Change

If your changes routinely arrive as one large pull request and reviews come back with a mix of blocking and trivial comments, this pattern is worth adopting regardless of which forge you use. The tooling makes it cheaper; the discipline of splitting a change into layers that each stand on their own is where the benefit comes from, and that part is free.

If your review bottleneck is instead that reviews take days to start, stacking will not help. Smaller pull requests get reviewed faster only when someone is actually looking.

We build and maintain CI/CD pipelines and review workflows as part of DevOps as a service. If you want a second opinion on whether this fits how your team ships, get in touch.

Sources: GitHub Changelog, July 30 2026, About stacked pull requests, github/gh-stack