GitHub

Stacked Pull Requests Arrive on GitHub in Public Preview

GitHub's stacked pull requests enter public preview: review each layer independently, merge a stack in one click, plus a gh-stack CLI extension and Copilot coding-agent skill.

Stacked Pull Requests Arrive on GitHub in Public Preview — article cover
On this page6 SECTIONS
  1. What a Stacked PR Is
  2. Getting Started: CLI Extension and the gh-stack Skill
  3. Layer-by-Layer Review and One-Click Merging
  4. Feedback from Large Codebases
  5. What It Changes for Development Workflow
  6. Sources

On July 30, 2026, GitHub announced that stacked pull requests are in public preview, rolling out to all repositories over the coming days. This is a platform-level feature, not an extension: your existing reviews, checks, and merge requirements all work as before. What changes is that a large piece of work no longer has to squeeze into one giant pull request.

What a Stacked PR Is

A stack is an ordered series of pull requests, each representing one focused layer of the change. It targets two old problems: the single enormous PR that takes forever to review, and the manual juggling of multiple branches with endless rebasing. GitHub frames stacks as a way to keep large changes moving by reviewing narrowly scoped pull requests in parallel, and to merge one, some, or all of them — the whole stack at once, or individual layers as they become ready. With stacks, a team can review short, focused pull requests side by side, then land everything together.

Getting Started: CLI Extension and the gh-stack Skill

The entry point is one command: gh extension install github/gh-stack. GitHub says you can create your first stack in under a minute: start with a branch and pull request for the first change, then add branches and pull requests on top; each pull request targets the layer below it. Stacks work on github.com, the GitHub CLI, and the mobile app — and coding agents such as GitHub Copilot can build stacks through the gh-stack skill. In an era where AI produces large volumes of code, that path is clearly a design priority.

Layer-by-Layer Review and One-Click Merging

When reviewing, you open any pull request in the stack and see only the diff for that specific layer; a stack map at the top shows how it fits into the larger work. Teammates can each take different layers in parallel without blocking each other. Because every layer is an ordinary pull request, the reviews, branch protections, and required checks you already enforce keep applying, so quality gates hold at each step of the stack rather than only at the final merge to main. Merging has two granularities: merging the latest ready pull request lands it and every unmerged layer below it in one operation, while merging a lower layer leaves the pull requests above it open, automatically rebased and retargeted. Merge queue support is rolling out progressively over the coming weeks.

Feedback from Large Codebases

The changelog’s cast of testers carries weight. Tim Neutkens, Next.js lead at Vercel, said his team has used GitHub stacked PRs for the past few months to ship larger features as smaller individual changes, making PRs easier to review. John Resig, creator of jQuery, called the preview “incredible” — landing five stacked PRs straight into a merge queue at once. Andy Merryman, CTO of TED, named the core pain point: AI made developers dramatically more productive, and PRs grew so large that reviewers struggled; breaking changes into small, dependency-ordered pieces made reviews not just faster but more accurate. A WHOOP engineer put it best: “It stopped feeling like a tool on top of GitHub and started feeling like GitHub.”

What It Changes for Development Workflow

What matters is not only the feature but who is making it a default. Stacked-PR workflows previously depended on third-party tools and homegrown scripts; baking them into the platform is an official endorsement of small commits reviewed layer by layer. Set it against the other trend of 2026 — coding agents producing hundreds of lines per run while human reviewer attention becomes the bottleneck — and stacked PRs look like GitHub’s answer: cut agent output into dependency-ordered, reviewable layers so review keeps pace with generation. The division of labor is explicit: agents generate the layers, humans approve them one at a time. Feedback is being collected through the stacks discussion during the preview. If stacked PRs follow the path of merge queues from preview to standard equipment, the unit of code review may slowly shift from “a pull request” to “a stack.” Teams that already reviewed in layers will find the friction gone; teams that did not now have one less excuse for four-hundred-line pull requests.

Sources

AI-assisted summary compiled from the sources above, reviewed by a human before publishing.

SHAREXEMAIL