On 30 July, GitHub pushed stacked pull requests into public preview for every repository. On the surface it is a workflow convenience: a way to break one large change into an ordered chain of smaller pull requests, each targeting the branch below it rather than main. In practice it is something more consequential. It is GitHub conceding that the single-branch, single-PR model it has trained an entire industry on does not survive contact with the volume of code teams are now producing.
The pattern itself is not new. Meta and Google have run stacked diffs internally for roughly a decade, and Graphite has sold a polished version of it to GitHub users since 2022. What changed is that stacking is now native, free, and, critically, invisible to reviewers. That last point is the one that matters most, and it is worth understanding why before your team rushes to adopt it.
TL;DR
- GitHub shipped stacked pull requests to public preview on 30 July 2026, available on all repositories via
gh extension install github/gh-stack, the web UI, mobile, and Copilot. - Each pull request in a stack targets the branch below it, so layers can be reviewed in parallel and merged bottom-to-top in a single operation, with upper layers auto-rebased.
- The driver is volume: GitHub projects around 14 billion commits in 2026 against roughly one billion in 2025, largely because AI coding agents generate far larger diffs than humans do.
- Analysis of 1.5 million pull requests found changes in the 200 to 400 line range are approved roughly three times faster and carry about 40% fewer defects than large ones.
- Real limitations remain: squash and rebase merges rewrite commit hashes and break stack tracking, merge queue support is still rolling out, and cascading rebase conflicts are unsolved.
- Stacking is a decomposition discipline, not a tool install. Teams that cannot already split work into logical layers will not benefit from it.
What actually shipped
The mechanics are straightforward. You install the extension, initialise a stack, and add branches to it:
gh extension install github/gh-stack
gh stack init feature/db-schema
gh stack add feature/api-routes
gh stack add feature/ui-components
gh stack submit
Each branch becomes a pull request whose base is the branch beneath it. GitHub renders a stack map inside the pull request interface showing where each layer sits in the chain, so a reviewer opening the API routes PR sees only the API routes diff, not the schema migration underneath it.
Two implementation details deserve attention. First, existing branch protections and required status checks work without modification, and CI runs as though each pull request targeted main directly. That removes the most common objection to third-party stacking tools, which frequently sat awkwardly alongside repository policy. Second, gh stack sync rebases the entire chain and force-pushes each branch when something upstream changes, and a single merge lands the ready pull request along with every unmerged layer below it.
There is also a Copilot integration via gh skill install github/gh-stack, which lets coding agents create and manage stacks directly. That is not a footnote. It is the whole point.
The volume problem nobody wants to name
GitHub’s own numbers explain the timing better than any product narrative. The platform projects roughly 14 billion commits in 2026, against something close to one billion in 2025. That is not fourteen times more engineers. It is agents committing at machine speed while the review layer stayed exactly as fast as it was, because it is still staffed by people.
We have written before about the code review bottleneck and the verification problem this creates. Stacked pull requests are the first serious piece of platform infrastructure aimed squarely at it. The logic is sound: if the constraint is reviewer attention rather than code production, then the highest-leverage intervention is reducing the cognitive load per review, not accelerating the review itself.
The supporting evidence is reasonable. Research across 1.5 million pull requests found that changes in the 200 to 400 line band are approved around three times faster than larger submissions and ship roughly 40% fewer production defects. Anyone who has been handed a 2,000 line pull request on a Friday afternoon already knows why. Past a certain size, reviewers stop reviewing and start pattern-matching, and pattern-matching does not catch logic errors.
Where it is still rough
This is a public preview, and it shows in one specific and irritating place: squash merges.
Squashing rewrites commit hashes. GitHub’s stack tracking depends on commit identity to know which branch belongs where in the chain, so squash-merging an intermediate pull request breaks the link and requires a manual gh stack rebase to reassemble. Standard merge commits are currently the only reliably safe option for intermediate layers. If your organisation mandates squash merges for a clean linear history, and a great many do, this is a genuine blocker rather than a minor annoyance. Graphite has spent years grinding down exactly this edge case, which is a fair reminder that native does not automatically mean mature.
Merge queue support is also arriving progressively rather than all at once, so verify it is live on your repository before restructuring anything. And cascading rebase conflicts remain what they have always been: when a change lands three layers down, everything above it has to move, and gh stack sync automates the mechanics without automating the judgement.
Does this kill Graphite?
Not immediately, but it compresses the space Graphite occupies. Graphite’s free tier already includes stacking and its paid plans start at $20 per developer per month, and it retains stack-aware merge queues plus years of resolved edge cases. What it cannot match is zero reviewer setup.
That was always the quiet killer for third-party stacking tools. The engineer who wanted stacked diffs could install the CLI in five minutes. Getting fourteen reviewers, three of them contractors and one of them the CTO who opens pull requests on a phone, to adopt a separate review surface was the part that never happened. Native stacking sidesteps that entirely, because reviewers do not need to know a stack exists.
Should your team adopt it
Three honest questions before you restructure anything.
Can your team already decompose work into logical layers? Stacking rewards teams that naturally think in terms of schema, then service, then interface. If your feature branches are undifferentiated blobs because nobody planned the change before writing it, stacking will simply give you the same blob split across four pull requests with dependency overhead attached. The tool does not supply the discipline.
Is review latency actually your constraint? Measure it. If pull requests sit for two days waiting on a reviewer, stacking helps because layers can be reviewed in parallel. If they sit for two days because your CI takes forty minutes and flakes twice a week, you have a different problem and stacking will make it worse by multiplying the number of CI runs.
What is your merge strategy? If squash merges are non-negotiable in your organisation, wait for the next iteration. The workaround is real but it will erode adoption within a fortnight.
For teams that clear all three, the sensible entry point is a single willing squad running stacks on one repository for a month, with a written convention on maximum stack depth. Three to four layers is manageable. Eight is a rebase nightmare wearing a workflow costume.
The broader signal
Strip away the tooling and stacked pull requests are an argument about where engineering effort belongs in 2026. When generating code was expensive, it made sense to optimise for writing it. Now that generation is close to free and comprehension is the scarce resource, the optimisation target moves to the review layer, and the shape of the work has to change to suit the humans still doing the verifying.
That is the same reasoning behind spec-driven development, tiered review policies, and the structural guardrails teams are adding to CI. Stacked pull requests are one more instance of the pattern: constrain the size of what a person has to hold in their head, and quality follows. It is a modest feature with a fairly serious thesis underneath it.
At REPTILEHAUS we build and run delivery pipelines for teams navigating exactly this shift, from CI/CD architecture and DevOps to the governance layer around AI coding agents. If your review process is buckling under the volume your team is now capable of producing, get in touch and we will look at where the constraint actually sits before recommending you change anything.
📷 Photo by Sean Stratton on Unsplash
