Ever spent 45 minutes reviewing a 3,000-line pull request? You’re not alone. Code review on monolithic PRs remains one of the worst bottlenecks in the development cycle. On July 30, 2026, GitHub finally shipped a credible answer to this problem with the public preview of Stacked PRs.
I’m Mehdi Rahmani, a freelance security and DevOps consultant, breaking down this major release for you. The promise is simple: split a large feature into several focused PRs, chain them logically, review them independently, and merge everything with a single click. Let’s see how it plays out in practice.
What Are GitHub Stacked PRs?
Stacked PRs are an ordered series of pull requests, each representing a focused layer of a larger change. Every PR in the stack targets the layer below it, not the main branch directly. The whole thing forms a dependency chain that GitHub manages natively.
In concrete terms: instead of opening a single 2,000-line PR that terrifies your reviewers, you create four 500-line PRs. Each one can be reviewed in parallel by different people. The status of every layer is visible at a glance from the GitHub interface. And when everything is ready, you merge the entire stack in a single operation.
This approach already existed through third-party tools like Graphite or Git Town. What’s different here is the native integration: your branch protection rules, required checks, and merge queues work without any adaptation. Quotes from the official announcement: Tim Neutkens, Next.js lead at Vercel, confirms the team has been using Stacked PRs for several months to “introduce smaller individual changes while shipping larger features.” John Resig, creator of jQuery, calls the experience “incredible” after merging five stacked PRs at once through the merge queue.
Why DevOps Teams Have Been Asking for This for Years
Anyone working in a substantial codebase knows the problem. Large PRs create three major friction points:
- Endless reviews: a reviewer handed 3,000 lines to analyze will either skim or procrastinate. In both cases, the code stagnates.
- Cascading merge conflicts: when multiple developers work on long-lived branches, rebases become a logistical nightmare.
- Late feedback: a monolithic PR concentrates all feedback at the end of development. Architectural mistakes get caught far too late.
Stacked PRs tackle all three problems at the root. Each layer is small enough to be reviewed quickly. Rebases propagate automatically along the stack through a cascading mechanism. And feedback arrives incrementally, layer by layer.
Andy Merryman, CTO of TED, sums up the stakes well in the GitHub changelog: “AI has made our developers significantly more productive, but it created a new bottleneck: PRs were becoming too large for reviewers. Stacked PRs help solve that.”
How It Works in Practice
Setup via the CLI
Access to the public preview requires no waitlist. A single command does it:
gh extension install github/gh-stack
You then create your first stack in a matter of minutes. The feature is available from the terminal, the github.com web interface, the GitHub mobile app, and even through GitHub Copilot via the gh-stack skill.
Navigation and Per-Layer Review
Each PR in the stack displays a diff containing only the changes specific to its layer. A visual map at the top of the PR shows where the layer sits within the overall work. You immediately see the number of PRs, their status, and the dependency order.
Your teammates can review different layers in parallel without blocking each other. Branch protections and required checks continue to apply normally.
One-Click Merge via the Merge Queue
This is the standout feature of the native integration. You merge the topmost PR in the stack, and all unmerged layers below it land on main in a single operation. If you want to merge only part of the stack, merge a lower layer: the PRs above stay open and rebase automatically onto the new target.
The merge queue supports Stacked PRs progressively: compatibility is rolling out over the weeks following the release.
Early Reactions: Enthusiasm and Teething Bugs
The launch generated massive excitement. Teams that had been testing the preview internally for several months, like those at Next.js and TED, are reporting very positive results.
Mayank Saini, connectivity engineer at WHOOP, testifies in the official announcement: “A big change used to mean a giant PR no one wanted to review. Now it’s a stack of small PRs that reviewers can actually follow.”
However, the public preview also reveals some fragility. Several users report that merging an entire stack can fail in complex cases, especially when subtle conflicts arise between layers during the merge operation. Squash-and-merge mode also poses issues: if reviews are mandatory, each PR in the stack requires re-approval after squashing, which breaks the promise of a smooth flow.
The GitHub team has not yet officially addressed these points. Discussion remains open on the github/gh-stack repository, and fixes will depend on community feedback during this preview phase.
Native Stacked PRs vs. Third-Party Tools: Too Early to Call?
One question keeps coming up in every discussion: what’s the future for Graphite, Git Town, and other specialized tools?
The answer is nuanced. The public preview is too fresh to draw a fair comparison. Third-party tools have years of maturity, battle-tested workflows, and advanced features that GitHub does not yet integrate. But the native integration has one massive advantage: it requires no habit changes, no team onboarding, no additional paid contract.
If GitHub quickly fixes the merge bugs and relaxes the squash-and-merge behavior, the ecosystem of specialized tools will have to differentiate on advanced use cases. Conversely, if the preview remains fragile for several months, teams that have already adopted Graphite will have no reason to switch.
Key Takeaways
- Stacked PRs are available in public preview since July 30, 2026, with no waitlist.
- They let you chain dependent PRs, review them in parallel, and merge everything with one click via the merge queue.
- The native integration respects branch protections, required checks, and existing workflows.
- Teething bugs remain around full-stack merging and squash-and-merge behavior.
- The impact on third-party tools like Graphite will depend on how fast GitHub ships fixes in the coming months.
If you’re testing Stacked PRs on your projects, I’m curious to hear your feedback. Drop by mehdi-rahnani.dev or follow the blog so you don’t miss the next analyses.
Sources
- GitHub Changelog: Stacked pull requests are now in public preview, July 30, 2026
- Official gh-stack documentation, GitHub
- github/gh-stack repository: merge bug discussions, GitHub Community