GitHub has rolled stacked pull requests out to public preview across all repositories, giving teams a native way to split large changes into an ordered series of small, independently reviewable pull requests that merge together in a single click. It’s a workflow that third-party tools like Graphite have championed for years — but now it ships built into the platform, with existing branch protections, required checks, and reviews working out of the box.
What Stacked PRs Actually Do#
A stack is a chain of pull requests where each one targets the layer below it instead of main. You open a branch and PR for your first change, then add another branch and PR on top of it, and so on. The result is a linear sequence of small diffs instead of one sprawling pull request that tries to represent an entire feature at once.
Reviewers get a “stack map” at the top of each PR showing exactly where that layer sits inside the larger change, so they can review one focused diff without losing sight of the bigger picture. Multiple reviewers can work through different layers in parallel, and merging the latest ready PR lands it — plus every unmerged layer beneath it — in one operation. Merge only part of a stack, and the PRs above it stay open, automatically rebasing and retargeting against the new base.
You can create and manage stacks from github.com, the GitHub CLI (via gh extension install github/gh-stack), the mobile app, or a coding agent like GitHub Copilot using the accompanying gh-stack skill. Merge queue support is rolling out progressively over the following weeks.
Why Now: The AI-Generated PR Problem#
The timing isn’t incidental. As AI coding assistants generate more of the diff, the bottleneck has shifted from writing code to reviewing it — a theme that keeps surfacing across AI-assisted testing and AI-powered code review tooling. TED’s CTO Andy Merryman put it plainly in GitHub’s announcement: “AI has made TED’s developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling.” Breaking changes into dependency-ordered layers doesn’t just speed up review — TED reports it makes reviews more accurate, because each layer is small enough to actually reason about.
That’s the real value proposition here. Once an agent — or a human working alongside one — can generate a thousand-line change in minutes, the review process becomes the actual constraint on shipping. Stacked PRs don’t reduce the total amount of code; they reduce the cognitive load of reviewing it by forcing decomposition at the point of authorship rather than leaving it to a reviewer to untangle after the fact.
Who’s Already Using It#
The quotes GitHub gathered for the launch read less like marketing copy and more like relief. Next.js lead Tim Neutkens says Vercel has used stacked PRs “for the past few months” to ship larger features as smaller individual changes. jQuery creator John Resig described landing five stacked PRs directly to a merge queue in one shot as removing “so much friction.” WHOOP engineer Mayank Saini’s line is the sharpest summary of the pitch: “It stopped feeling like a tool on top of GitHub and started feeling like GitHub.”
That distinction matters. Stacking workflows have existed for years through Graphite, git-branchless, and raw multi-branch juggling, but they all lived on top of GitHub rather than inside it — meaning separate accounts, separate UIs, or manual rebase choreography. Native support means your existing branch protections, status checks, and review requirements apply automatically, without a second tool mirroring state between two systems.
What’s Still Rolling Out#
This is a public preview, not a finished feature. Merge queue integration is arriving progressively rather than all at once, and teams that have built internal tooling or muscle memory around Graphite-style stacking will want to watch how GitHub’s native rebase-and-retarget behavior handles edge cases — conflicting layers, force-pushes mid-stack, and CI re-runs across every layer when a lower one changes are the places these systems tend to get complicated. GitHub is soliciting feedback directly through a dedicated discussion thread, which is usually a sign the interaction model is still being tuned based on real usage rather than locked in.
Teams already running platform engineering practices that standardize how code moves from commit to production should treat this as a workflow change worth piloting on one team before mandating it — the payoff scales with PR size and team review load, so a five-person team shipping small diffs won’t feel the same lift as a codebase absorbing large, AI-assisted changes daily.
My Take#
Stacked PRs are GitHub admitting, implicitly, that the single-giant-PR model was already buckling under AI-assisted development before this feature existed — it just took a public preview to make the fix official. The quotes from Vercel, TED, and WHOOP aren’t unusual enthusiasm; they’re teams describing a bottleneck they’d already worked around informally, now getting first-class support. What I’d watch next isn’t the feature itself but the tooling built around it: as Copilot’s agent mode and other coding agents generate larger diffs autonomously, expect agents to start authoring stacks directly rather than single PRs, splitting their own output into reviewable layers before a human ever sees it. That’s the version of this feature that actually changes review economics — not humans manually chopping up big changes, but agents that never generate an unreviewable one in the first place. Combined with the direction LLM agents in production are already heading, stacked PRs look less like a GitHub convenience feature and more like infrastructure the next generation of coding agents will assume exists.
