GitHub Stacked Pull Requests Reach GA for Smaller Reviews

Nobody really reviews a 2,000-line pull request. They scroll, type LGTM and hope the tests were right. GitHub made stacked pull requests generally available on October 6, 2026, on all github.com plans, and the idea is simple: split one big change into a chain of small pull requests that are reviewed separately and land together.

What GitHub shipped for stacked pull requests

A stack is two or more pull requests in the same repository. The bottom one targets your trunk (usually main) and each one above it targets the branch below. Foundations go low, dependent code goes high. Per the GitHub docs on stacked PRs, you can merge the whole stack, one pull request or part of it, always from the bottom up.

The GA changelog adds the pieces that matter in a real repo:

• Rebase stack keeps approvals. When an otherwise unchanged stack is updated because main moved, approvals survive, even in repos that dismiss stale approvals. The replacement commits are signed and keep their original authorship.
• Merge queue support. A stack enters and lands through the merge queue as a single merge group. With the merge commit method, you get one merge commit per pull request, not one for the whole group.
• Automatic retargeting. If a stack's base branch is deleted, GitHub retargets the stack instead of closing the bottom pull request.
• Smaller upgrades. Stack info sits in the pull request header, Shift+J and Shift+K jump between layers, the pull_request webhook has a new stacked action, and the gh stack CLI extension now supports Git worktrees.

GitHub also reports that repos using stacks merged 9% more code than their peers, and that over two-thirds of the top 1% of repos use them, with a 5% better time-to-merge. Those are GitHub's numbers, and the announcement gives no methodology. Treat them as a hint and measure your own repos.

Why stacked pull requests suit AI-generated changes

Coding agents make big diffs cheap. Reviewer attention is the part that doesn't scale. A stack lets you, or the agent, cut a diff along its natural seams: the refactor first, the new behavior second, the wiring last. Each layer gets a focused review, and a reviewer can approve layer one while still arguing about layer three.

Infrastructure repos have the same shape. A Terraform change could split into the module change, then the environment config that uses it, then the rollout. That split is my suggestion, not something from the announcement, but it is the kind of dependency chain stacks were built for.

Try gh stack on Monday morning

You need GitHub CLI 2.90.0 or later and Git 2.20 or later, according to the quickstart.

gh auth login   # skip if you are already signed in
gh extension install github/gh-stack

# optional: the AI agent skill from the quickstart
gh skill install github/gh-stack

This installs the extension. The agent skill is optional, but it is the obvious thing to try if an agent is writing the code.

Now build a two-layer stack:

# Start a stack; trunk defaults to the repo's default branch
gh stack init

# Commit the first layer on the first branch
git add .
git commit -m "Extract retry helper"

# Stage everything, commit, and start the next branch in one step
gh stack add -Am "Use retry helper in the API client"

# Push all branches and create linked pull requests
gh stack submit --auto

# Check branches, PR links, and statuses
gh stack view

gh stack submit opens an editor for pull request details unless you pass --auto. After the bottom layer merges or main moves, gh stack sync --prune fetches, rebases if the trunk moved, pushes, syncs pull request state and removes merged branches. The full flag list is in the CLI reference.

Then, in order:

1. Pick one repo that already uses a merge queue.
2. Take the next agent-authored change that is bigger than your usual review size and split it into a stack.
3. Check your branch rules: signed commits and stale-approval dismissal are the cases the GA release specifically handles.
4. If you have automation on the pull_request webhook, decide what it should do with the new stacked action.

Limits to check before rolling out stacked pull requests

• Same repository only. Cross-fork stacks aren't supported, and GitHub Desktop doesn't support stacks.
• Not on Enterprise Server yet. It is promised for an upcoming GitHub Enterprise Server release.
• Auto-merge for stacks is still rolling out. GitHub says it arrives over the next few weeks, so you may not see it yet.
• Mid-stack merges pull in everything below. The layers above stay open and retarget the base branch.
• API merges. Use the asynchronous merge API for stacks.

If your agents write more code than your team can read, stacks keep each review human-sized without slowing the merge, which is exactly the bottleneck production AI work hits.