GitHub Stacked Pull Requests Are GA: What Changes for CI and Merges

Stacking used to be a workflow you bolted onto GitHub with third-party tools and a lot of rebasing. It is now a native feature with its own merge rules. The developer experience is the headline; the rule changes are what will surprise your CI.

This is a practical read of what GA changes, built from GitHub's concept docs, the reference page and the GA changelog.

What a stack is on GitHub

A stack is two or more pull requests in the same repository. The bottom one targets the trunk, usually main but any branch such as a release branch works; each PR above targets the branch of the PR below it. Each PR shows only its own layer's diff, and a stack map in the merge box shows every layer and its status.

The docs state the one rule you have to design around: "if code in one layer depends on code in another, the dependency must be in the same branch or a lower one." Shared types and schema go low; API routes and UI go high.

GitHub's GA post also gives adoption numbers from the preview: repositories using stacks merged 9% more code than peers, and over two-thirds of the top 1% of repositories use them, with a 5% improvement in time-to-merge. Those are GitHub's figures and correlational, but they explain why this shipped as a platform feature rather than staying an extension.

The CI and protection change most teams will miss

With hand-rolled stacks, only the bottom PR targeted main, so only it got main's branch protections and the CI that runs on PRs to main. Native stacks fix that. Per the reference, every PR is evaluated as if it targets the stack's base. That covers required reviews, required status checks, CODEOWNERS and code scanning.

Consequences worth checking before rollout:

• Workflow filters. GitHub Actions workflows trigger for every PR in the stack as if it targets the base, so a workflow filtered to branches: [main] now runs on mid-stack PRs too. Good for coverage, but more runner minutes on deep stacks.
• Stack-aware jobs. The github.event.pull_request.stack property is present only for PRs in a stack, which is how a workflow can skip expensive jobs on upper layers if you decide that is acceptable.
• CODEOWNERS edits. A change to CODEOWNERS in a lower PR affects that PR's evaluation, not the PRs above it.
• Merge gate. A PR can merge only if it and every PR below it meet all protection requirements, and the stack has a fully linear history.

If you recently moved to rulesets, nothing about the rules themselves changes; what changes is which PRs they now reach. Our note on GitHub Actions workflow lockfiles is a reasonable companion if you are already reviewing what runs on every PR.

How merging works now

Merging the top PR merges every PR below it. Merging a mid-stack PR merges it and everything beneath; the PRs above stay open and retarget the stack's base automatically. PRs always land bottom-up.

The GA release changed several details:

• Stacks enter and land through the merge queue as a single merge group. The queue can exceed its configured maximum group size by up to 50% to keep a stack together; a stack too large for that buffer is split across consecutive groups. If a PR is removed or ejected from the queue, every PR above it is removed too.
• With the merge commit method, GitHub now creates one merge commit per pull request rather than one for the whole group, according to the GA changelog. Squash produces one commit per PR; rebase replays commits for linear history.
• Auto-merge for stacks was described as rolling out over the weeks after GA. Once every PR in the selected group meets requirements, they merge together.
• If a stack's base branch is deleted, GitHub retargets the stack instead of closing the bottom PR, which makes stacks on top of other stacks workable.

The resulting history matches what you would get by merging each PR individually from the bottom, which is the property that keeps git bisect and changelog tooling sane.

Rebasing without losing approvals

Linear history is a strict merge requirement, and you lose it whenever someone pushes to a lower branch or main moves. The fix is a cascading rebase: Rebase stack in the merge box, or gh stack rebase followed by gh stack push locally.

Two GA details make server-side rebase the better default. Rebase stack keeps approvals for unchanged code, even in repositories that dismiss stale approvals. And GitHub signs the replacement commits it creates while keeping original authorship; automatic rebases after partial merges also sign when branch rules require signatures or any original commit was signed. That removes the main reason teams with signed-commit rules avoided rebasing stacks in the browser.

The gh stack CLI in five commands

The CLI is optional; the docs say standard Git and the website both work, and tools such as Jujutsu or Sapling can push branches you then open as a stack. The gh-stack extension needs GitHub CLI 2.0+ and Git 2.36+:

gh extension install github/gh-stack gh stack init --base main     # start a stack on a trunk gh stack add -m "add schema"  # new branch on top, commit staged changes gh stack submit               # push, create/update PRs, link them as a stack gh stack sync --prune         # after merges: rebase, push, clean up

Navigation is up, down, top and bottom, and gh stack modify opens a TUI to reorder, fold or drop branches (it needs a clean tree and linear history). The GA release added Git worktree support: stack metadata is shared across linked worktrees, and rebase/sync refuse to touch a worktree that is dirty or busy rather than auto-stashing. For agents, gh skill install github/gh-stack installs the skill GitHub mentions for Copilot and other coding agents.

Limits to check before you roll it out

The API point is the one most likely to break something quietly. If a bot merges PRs with the synchronous endpoint, it needs updating before anyone stacks; we covered that API in GitHub's async merge API. Automation can also listen for the stacked action on the pull_request webhook, and payloads include a stack object. If you are inspecting those payloads by hand, a JSON formatter helps.

Should your team switch?

If you already stack with a third-party tool, the native version is worth a trial mainly for the protection and CI semantics: upper layers finally get the same checks as the bottom one, without workarounds. If you have never stacked, start where it pays off most, which the docs themselves name: high-volume sequential work, including AI agents completing one task per PR. Keep stacks shallow at first; every layer runs your full PR CI.

For alternatives and companion tools, browse the developer tools directory or the open-source listings.

FAQ

Are GitHub stacked pull requests available on the free plan?

Yes. GitHub says stacked pull requests are generally available on all github.com plans as of 6 October 2026. GitHub Enterprise Server support is planned for an upcoming release.

Do I need the gh stack extension to use stacked PRs?

No. The extension is helpful but optional. Stacks can be created on github.com, in GitHub Mobile, with standard Git, or with other tools such as Jujutsu or Sapling that push branches you then link as a stack.

Do required status checks run on every PR in a stack?

Yes. Every PR in a stack is evaluated as if it targets the stack's base branch, so required checks, required reviews, CODEOWNERS and code scanning apply to mid-stack PRs, and GitHub Actions workflows trigger for each of them.

Can a stack include pull requests from a fork?

No. All branches in a stack must live in the same repository, so cross-fork stacks are not supported.

What happens to approvals when I rebase a stack?

Using Rebase stack on GitHub keeps approvals for unchanged code, even in repositories that dismiss stale approvals, and GitHub signs the replacement commits while keeping original authorship.

Stacks used to be a way around GitHub's review model. Now they are part of it, and the rules apply to every layer.