⏱️ Lectura: 9 min
On July 30, 2026, GitHub opened the public preview of stacked pull requests for all repositories on the service. The feature splits a large change into an ordered series of small PRs, each focused on a specific layer, and lets you merge the entire stack with a single click.
📑 En este artículo
The goal is simple: put an end to the thousand-line PR that nobody wants to review, without forcing the team to manage manual branches that need to be rebased by hand every time a lower layer changes.
TL;DR
- GitHub launched the public preview of stacked pull requests for all repositories on July 30, 2026.
- The feature splits a large change into an ordered chain of PRs, each focused on a specific layer.
- Each PR in the chain is reviewed and tested separately, with main’s branch protections unchanged.
- Merging the topmost layer lands that layer and all the ones below it in a single operation.
- It’s installed with
gh extension install github/gh-stackfrom the GitHub CLI. - It works from github.com, the CLI, the GitHub mobile app, and agents like Copilot with the gh-stack skill.
- Merge queue support for stacks is rolling out progressively over the coming weeks.
- Tim Neutkens (Next.js, Vercel) and Andy Merryman (CTO, TED) confirm they’re already using stacks to speed up reviews.
Introduction
Stacked pull requests describe a pattern that already existed in external tools, but now lives natively inside GitHub. Instead of a single monolithic PR, the developer builds a chain of branches: each one builds on the previous one and opens as an independent pull request that points to the layer below, not directly to main.
Each PR in the chain is reviewed, tested, and approved separately. Existing checks, required reviews, and main‘s branch protections keep applying unchanged, according to the official GitHub changelog.
What happened
The announcement came on July 30, 2026 through GitHub’s changelog, which confirms the feature is rolling out “to all repositories over the coming days”. Merge queue support for stacks is progressing separately, in a gradual rollout over the coming weeks.
Tim Neutkens, Next.js lead at Vercel, said the team had already been using stacked pull requests for months: “It has helped us introduce smaller individual changes while shipping larger features, making it easier to review PRs,” according to the quote GitHub included in its changelog.
The workflow works the same way from github.com, the GitHub CLI, the GitHub mobile app, or an agent like GitHub Copilot using the gh-stack skill. There’s no need for a different client for each layer of the stack.
Context and history
Splitting a large change into a chain of dependent commits or branches isn’t a new idea. Tools like Phabricator, used internally at Meta, or Graphite, an external layer on top of Git and GitHub, popularized the “stacked diffs” workflow among teams that prioritize small, frequent reviews.
The difference with this feature is that it now lives inside GitHub without installing an external service or paying for a third-party tool. The stack is stored as a normal sequence of branches and pull requests: no proprietary metadata that only an external client can understand.
Before this feature, the practical problem was manual rebasing: if the developer touched layer 1 of the stack, they had to manually update layers 2 and 3 and reopen each PR. With native stacks, that rebase and retargeting happen automatically when a lower layer gets merged.
Technical details and performance
Each pull request in a stack points to the layer below instead of pointing directly to main. When you open any PR in the chain, GitHub shows a “stack map” at the top that places that layer within the rest of the change.
flowchart TD
A["PR 1: data model"] --> B["PR 2: /payments endpoint"]
B --> C["PR 3: integration tests"]
C --> D[("main")]Merging works by layers: merging the topmost PR that’s ready lands that layer and all the layers below it that are still unmerged, in a single operation. If the team only merges the lower layers, the upper ones stay open and rebase and retarget themselves against the new base.
💭 Key point: main’s branch protections and required checks still govern what gets into the repository: stacked pull requests aren’t a shortcut to skip reviews, they just change how reviews are organized.
Andy Merryman, CTO of TED, described the problem it solves: “AI has made TED’s developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling. Stacked PRs help to solve that.” With AI generating more code per developer, the bottleneck shifted from writing code to reviewing it.
John Resig, creator of jQuery, summed up his experience with the merge queue workflow: “Landing 5 stacked PRs directly to a merge queue all at once! A+++! This removes so much friction (and the gh cli tools + agent skill help a ton).”
| Interface | When to use it | Advantage | Limitation |
|---|---|---|---|
| github.com | Reviewing and approving layers without leaving the browser | Visual stack map built into every PR | Creating new branches is still manual from the web |
| GitHub CLI (gh-stack) | Creating and reordering the stack from the terminal | Automates branching, pushing, and opening a PR per layer | Requires installing the extension separately |
| GitHub mobile app | Approving or commenting on a specific layer from your phone | Notifications per layer, not per giant PR | Not designed for creating the stack, only for reviewing it |
| Copilot with gh-stack skill | Delegating creation of an entire stack to an agent | The agent builds the layers following the same flow as the CLI | Depends on the agent having the skill installed |
Getting started
To create your first stack you need the GitHub CLI (gh) and the gh-stack extension. Installing gh varies depending on the operating system:
# macOS (Homebrew)
brew install gh
# Windows (winget)
winget install --id GitHub.cli
# Linux (Debian/Ubuntu, via apt)
type -p curl >/dev/null || sudo apt install curl -y
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo apt update
sudo apt install gh -yWith gh installed, the next step is adding the official extension. The command is the same on macOS, Windows, and Linux:
gh extension install github/gh-stackAfter that, a typical workflow for building a two-layer stack on a repo called api-pagos looks like this:
# Layer 1: add the data model
git checkout -b feature/pagos-modelo
git commit -am "add Payment model and migration"
gh stack push
# Layer 2: add the endpoint that uses the model above
git checkout -b feature/pagos-endpoint
git commit -am "add POST /pagos using the Payment model"
gh stack pushEach gh stack push opens or updates the PR for that layer, pointing to the branch below. To confirm the extension is installed, run gh extension list and look for github/gh-stack in the output.
Impact and analysis
TED’s case illustrates the most cited impact in the announcement: teams that already write more code per person thanks to AI assistants, but whose bottleneck shifted to human review. Splitting the change into layers doesn’t reduce the code written, but it does reduce the size of each diff a human has to read in one sitting.
For teams in Latin America that already use the GitHub CLI to automate releases or issues, adding gh-stack doesn’t introduce new infrastructure: it’s just one more extension on top of the same tool that’s probably already running in the CI pipeline.
💡 Tip: if your team already uses a merge queue on main, it makes sense to wait until that integration’s gradual rollout finishes before moving large stacks to production, since it’s still expanding over the coming weeks.
The real limitation is coordination: if a lower layer changes significantly after the upper ones have already been reviewed, the team has to re-review whatever got affected, even though the technical rebase is automatic. Stacked pull requests don’t fix a change that was poorly planned from the start, only one that was well planned but poorly packaged into a single PR.
What’s next
GitHub confirms the rollout to all repositories is continuing over the coming days, and that merge queue support for stacks is expanding gradually over the coming weeks. The official documentation and a discussion channel about stacks remain open for community feedback, according to the changelog.
There’s no public general availability date yet; for now the feature remains in public preview, which at GitHub usually means behavior changes before it stabilizes.
Try it yourself: install the extension with gh extension install github/gh-stack and build your first two-PR stack on a test repository today.
📖 Summary on Telegram: View summary
Frequently Asked Questions
What are stacked pull requests on GitHub?
It’s an ordered series of pull requests where each one represents a focused layer of a larger change. Each layer points to the branch of the previous layer instead of pointing directly to main, and gets reviewed separately.
Do I need to pay extra to use stacked pull requests?
GitHub’s changelog doesn’t mention any additional cost: the feature is described as part of the public preview rolling out to all repositories.
How is each layer of a stack reviewed?
By opening the PR for that specific layer, which shows only the diff for that layer along with a stack map that shows where it fits within the rest of the change.
What happens to main’s branch protections?
They keep applying unchanged. Required checks and mandatory reviews on main govern which layers can land, just like with a traditional PR.
When is merge queue support for stacks coming?
GitHub describes it as a gradual rollout over the coming weeks, separate from the rest of the feature, which is already in public preview.
Can I use stacks without the GitHub CLI?
Yes. The workflow works from github.com, the GitHub mobile app, and agents like GitHub Copilot with the gh-stack skill, in addition to the CLI.
References
- GitHub Changelog: official announcement of the stacked pull requests public preview, with quotes from Tim Neutkens, John Resig, Andy Merryman, and Mayank Saini.
- GitHub Docs: general documentation on pull requests, reviews, and branch protections on GitHub.
- GitHub CLI: official site for the command-line tool that supports extensions like gh-stack.
- github/cli: official repository for the GitHub CLI, the base for installing extensions like gh-stack.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Ferenc Almasi en Unsplash
0 Comments