GitHub shipped stacked pull requests to public preview on July 31, 2026, announced via @msdev: an ordered series of pull requests, each representing one focused layer of a larger change, reviewable in parallel and mergeable in a single operation. It's a feature the stacked-diff community (Graphite, Sapling, git-branchless) has been building third-party tooling around for years — now native to GitHub itself, and explicitly wired up for GitHub Copilot and other coding agents via a dedicated gh-stack skill.
TL;DR
| Question | Answer |
|---|---|
| What shipped? | Stacked pull requests, public preview |
| Announced | July 31, 2026, @msdev |
| What is a stack? | An ordered series of PRs, each one focused layer of a larger change |
| Where to use it | GitHub.com, GitHub CLI, GitHub mobile app, or a coding agent via the gh-stack skill |
| Review model | Parallel — teammates review different layers simultaneously, no blocking |
| Merge model | Merge the latest ready PR → lands it and every unmerged layer below it, one operation |
| Branch protections | Unchanged — existing protections and required checks still govern what reaches main |
| Coding agent support | GitHub Copilot, named explicitly, via gh-stack |
What a "stack" actually is
The core idea, straight from GitHub's own framing: stacked pull requests break large changes into small, reviewable pull requests — an ordered series where each PR is one focused layer, not the entire change dumped into a single diff.
Concretely, per the announcement thread:
- Start with a branch and pull request for your first change — this is layer one of the stack.
- Add further layers on top — each new piece of work becomes the next PR in the sequence, building on the branch below it.
- GitHub tracks the dependency order between these PRs and surfaces it as a stack map, so the full shape of the change stays visible even while individual layers are reviewed separately.
- Merging the latest ready PR lands that PR and every unmerged layer below it, in one operation — instead of a chain of manual merges and rebases up the stack.
That fourth point is the practical payoff most engineers who've used third-party stacking tools will recognize immediately: the tedious part of stacked-diff workflows has always been the rebase cascade — merge the bottom PR, then manually rebase every PR above it onto the new base, repeat for each subsequent merge. Native stacking support means GitHub itself understands and maintains that dependency chain, rather than developers hand-rolling it with branch naming conventions and careful rebase discipline.
Why parallel review is the actual headline feature
Traditional sequential small-PR workflows have a hidden bottleneck: PR #2 can't be meaningfully reviewed against a stable base until PR #1 merges, because PR #2's diff is computed relative to a branch that's still moving. In practice, teams either wait for each PR to merge before starting the next review (slow), or review against a moving target and re-review after every rebase (noisy).
GitHub's stacking model addresses this directly: "You and your teammates can each review different layers in parallel without blocking further work." The stack map keeps each layer's diff scoped to just that layer's changes, tracked against its position in the stack, so a reviewer looking at layer 3 doesn't need layers 1 and 2 to be merged first — they need the stack's dependency order to be understood, which GitHub now handles natively.
This is the same problem stacked-diff tooling like Graphite and Meta's internal Phabricator-style workflows have solved for years, now arriving as a first-class GitHub feature rather than a third-party wrapper layer. For teams already running trunk-based development with small, frequent PRs, this closes a real gap between "the workflow we want" and "the tooling GitHub natively supports."
The gh-stack skill: stacking meets coding agents
The detail most relevant to 2026's development landscape specifically: GitHub explicitly names coding agents such as GitHub Copilot as first-class stack participants, via a gh-stack skill. That's a deliberate acknowledgment of a real, current problem — agent-generated diffs tend toward one giant PR by default. Ask an agent to implement a feature end-to-end and, without explicit instruction otherwise, it will typically produce a single large commit or PR covering schema changes, business logic, tests, and UI in one pass, because nothing about the default agentic loop incentivizes decomposition.
A gh-stack-aware Copilot session changes that default: instead of one sprawling diff a human reviewer has to hold in their head all at once, the agent can decompose its own output into an ordered stack — schema migration as layer one, business logic as layer two, UI as layer three — each independently reviewable, each following the same merge-cascades-downward model as a human-authored stack.
This connects directly to a problem explainx.ai has covered from the human side: the review-time tax on AI-generated code — several developers in that "2x, not 10x" HN thread described reviewing agent output as taking 2-3x longer than writing the same code by hand, precisely because a large, unstructured diff is hard to verify carefully. Native, agent-aware stacking is one of the more concrete tooling responses to that exact complaint: shrink the unit of review, keep the dependency structure explicit, and parallel-review what used to be one unreviewable block.
How to try it
Per the announcement, stacks are usable through any of four surfaces:
| Surface | How you'd use it |
|---|---|
| GitHub.com | Native UI for creating and navigating a stack, including the stack map |
| GitHub CLI | gh commands for creating layers and managing the stack from the terminal |
| GitHub mobile app | Review individual layers on the go |
| Coding agents (e.g. GitHub Copilot) | Via the gh-stack skill — agent decomposes its own changes into stack layers |
The workflow shape, translated into steps:
- Open a branch and PR for your first focused change — this is the base of the stack.
- Continue working; each additional focused change becomes a new layer on top of the previous one.
- Reviewers pick up individual layers and review them in parallel — no need to wait for lower layers to merge first.
- When a layer is approved, merge the latest ready PR — GitHub lands it and every approved layer beneath it in a single operation.
- Branch protections and required checks apply throughout, exactly as they do for a standalone PR — stacking doesn't bypass any existing merge gate.
Where this fits if you're already using stacked-diff tools
Teams already on Graphite, Sapling, or git-branchless for stacked-diff workflows now have a genuine question to answer: does native GitHub support close the gap enough to drop the third-party layer, or do those tools still offer meaningfully more (richer CLI ergonomics, cross-repo stacks, more mature conflict handling)? GitHub being in public preview — not GA — matters here: expect rough edges, missing features relative to mature third-party tools, and likely rapid iteration before general availability. Evaluate it as "worth testing on a low-stakes repo now," not "safe to migrate your whole org's workflow to today."
What this means for AI-era PR sizes
The timing is not incidental. As agentic coding tools make it cheap to generate large amounts of code quickly, the bottleneck in software delivery has been visibly shifting from writing code to reviewing it — a theme that's shown up repeatedly across 2026's developer discourse, from Amdahl's-Law arguments about coding-only speedups capping total productivity gains to direct complaints about reviewing AI output taking longer than writing it would have.
Native, agent-integrated stacking is a structural response to that shift: instead of relying on discipline (asking an agent nicely to "keep PRs small") or hoping reviewers scale their attention to match larger diffs, the tooling itself enforces decomposition and enables parallel review as defaults. Whether it meaningfully reduces the review-time tax in practice — versus just formalizing a workflow disciplined teams already followed manually — is the open question this public preview exists to answer.
Summary
GitHub's stacked pull requests entered public preview on July 31, 2026: an ordered series of PRs, each a focused layer of a larger change, trackable via a stack map, reviewable in parallel by different teammates, and mergeable in one operation that lands the approved PR plus every unmerged layer beneath it. It's available on GitHub.com, the CLI, the mobile app, and — notably — through coding agents like GitHub Copilot via the gh-stack skill, a direct response to the AI-era problem of agents defaulting to one large, hard-to-review diff. Existing branch protections and required checks are unchanged. As a public preview, expect iteration before GA — worth testing now, not yet a wholesale replacement for mature third-party stacking tools if your team already relies on one.
Related on explainx.ai
- "2x, not 10x" — the review-time tax on AI-generated code
- Should developers stop reviewing AI-generated code? The debate
- Loop engineering — coding agents with Claude Code
- Agent skills — complete guide
- Claude Code commands — complete reference guide
- The AI Aesthetic — why AI apps converge on one look
- Top 10 open and closed-source agent harnesses (2026)
Source: @msdev announcement thread — July 31, 2026
Feature details reflect GitHub's public preview announcement as of July 31, 2026. Public preview features change before general availability — check GitHub's official docs for current behavior before relying on this workflow in production.