GitHub stacked pull requests go GA with 9% more merged code
GitHub announced general availability for stacked pull requests, which split a large change into small, independently reviewed pull requests that merge together at the end. If your branches keep blocking each other, GitHub’s numbers — 9% more merged code and 5% faster time-to-merge — justify adopting them now.
October 6, 2026. GitHub moved stacked pull requests to general availability, a year after they entered public preview on July 30, 2026. The idea fits in one sentence: split a large change into a series of small, independent review requests, linked to each other, that merge together at the end. Why it matters: it is the direct answer to the structural problem of the giant PR, the one that lingers for weeks because it bundles ten decisions into a single unreadable diff.
What general availability actually changes
The final release is more than a status change. GitHub added six mechanisms that fix the friction reported during preview.
The first concerns approval retention. When you rebase a stack whose base branch has moved ahead, Rebase stack now preserves existing approvals, even in repositories configured to dismiss stale approvals. For a team stacking five PRs, this ends the nightmare where a single rebase wipes out four validated reviews.
The second covers commit signing. The replacement commits created during a rebase remain signed and preserve original authorship, including during automatic rebases after a partial merge. Repositories that require signed commits by branch rule no longer break the stack.
Three adjustments simplify merging itself. Users with permission to bypass repository rules can now merge the lowest pull request in a stack with that right. A stack enters and leaves the merge queue as a single merge group, and the merge commit method now produces one commit per PR instead of one for the entire group. Finally, when a base branch is deleted, the stack is retargeted automatically instead of closing its bottom PR.
The last addition, auto-merge, rolls out over the coming weeks: select a group of pull requests and they merge together once all their merge requirements are met.
The preview numbers deliver the verdict
GitHub measured the effect on repositories that adopted the feature during preview. The results are clean: 9% more merged code than comparable repositories, and a 5% improvement in time-to-merge. More telling, over two-thirds of the top 1% of repositories already use stacked pull requests.
Translated for an engineering lead: this is not a comfort gadget, it is a measurable lever on delivery throughput. The 9% more code comes from the fact that a stack eliminates the coordination cost around a large PR — the review back-and-forth on a 3,000-line diff, the painful rebases, the dead branches waiting for a merge nobody wants to trigger.
Charlie Marsh, founder of Astral and of OpenAI, sums up the shift in one line quoted by GitHub: “It took one merge with GitHub’s Stacked PRs for me to conclude that it’s amazing.”
The workflow day to day
In practice, a stack is built by branching each PR off the previous one. The bottom PR carries the real base branch, the next branches off it, and so on. Review happens top-down or bottom-up depending on the team, but each diff stays small and readable — which is the whole point.
Navigation has been polished for GA. Stack context stays visible at all times in the PR page header, and two keyboard shortcuts — Shift+J and Shift+K — move between the PRs in a stack. The pull_request webhook now exposes a stacked action when a PR joins a stack, which opens the door to automating notifications and integration checks.
On the command line, the gh stack extension for the GitHub CLI supports Git worktrees and speeds up initialization, checkout and navigation. For agent workflows, that means a coding agent can manipulate a stack as cleanly as a human.
The discipline that makes or breaks a stack is not the tool, it is the review order. The most robust convention is to review bottom-up — the base PR first, then each PR upward — because the bottom PR sets the foundations that the rest extend. Reviewing out of order means validating floors whose foundations can still move, and it is the most common source of pointless re-reviews when a lower PR changes later. One simple rule beats a long document: never merge a PR until the one below it is approved.
Stacked PRs also change the reviewer’s job. Because each diff is small, a reviewer can clear a PR in minutes instead of carving out a half-hour block, and reviews can be distributed across the team in parallel. That is the less obvious driver behind the time-to-merge improvement: it is not just that the code merges faster, but that review capacity stops being the bottleneck.
One caveat remains: the feature is available on github.com for all plans, but it will only arrive in a future GitHub Enterprise Server release. GHES teams will have to wait before aligning their internal workflow with their public repositories.
Where it sits next to trunk-based and third-party tools
Stacked PRs are not a new idea: tools like Graphite, ghstack and Sapling have offered the same mechanic for a while, often outside GitHub, at the cost of a parallel workflow and extra tooling. The strength of the native version is that it brings the stack into the interface — stack state, approvals, signatures, the merge queue — right where the team already works, with no external dependency to install and maintain.
The deeper question for an engineering lead is where to draw the line between two delivery philosophies. Trunk-based development favors small, independent PRs merged quickly into main, using feature flags to hide unfinished code. Stacked PRs aim at the same goal — splitting — but keep the dependency relationship between pieces, which suits work where merge order matters, such as a schema migration followed by an API change.
The two approaches are not mutually exclusive. A mature trunk-based team will reach for stacks for the exception — the cross-cutting refactor touching five services — and keep small independent PRs for the rest. That is in fact what GitHub’s numbers suggest: adoption does not replace splitting, it structures it when the pieces are inseparable.
Verdict
If your team already splits changes into dependent branches, or if your PRs regularly block each other, adopt stacked PRs today: the 5% faster time-to-merge costs about a week of workflow adjustment, and approval retention on rebase removes the main operational risk. If your team already merges to trunk with small independent PRs, the gain will be more marginal — keep stacks for cross-cutting work that touches several layers at once. If you are on GHES, start preparing your review conventions now, but do not wait for the server release to train your developers on github.com. Either way, start small: a stack of two or three PRs on a real project, not a wholesale process redesign overnight.