GitHub Stacked Pull Requests Reach GA: Rebases, Signed Commits and Merge Queue Changes

What a stack is​

GitHub's documentation describes a stack as two or more pull requests in the same repository. The bottom pull request targets the trunk, usually main. Each later pull request targets the branch of the one below it. Foundational changes, such as shared types and database schema, go in lower branches. Code that depends on them, such as API routes and UI components, goes in higher branches.

Reviewers get a smaller diff for each layer. Developers can keep building on top of work that hasn't merged yet.

The usual reason given for this is AI-assisted coding. InfoQ framed the feature as a way to balance faster code generation, especially AI-assisted code generation, against limited human review capacity.

What GA adds​

GitHub's changelog lists these changes:

• Approvals survive rebases. When the base branch such as main moves ahead and the stack is otherwise unchanged, Rebase stack keeps approvals. This holds even in repositories that dismiss stale approvals.
• Signed replacement commits. Rebase stack creates signed replacement commits and preserves the original authorship. Automatic rebases after a partial merge also sign the replacements. That happens when branch rules require signatures or when any original commit was signed.
• Bypass permissions. Users who are allowed to bypass repository rules can use that permission to merge the lowest unmerged pull request in a stack.
• Merge queue behavior. A stack enters and lands through the merge queue as a single merge group. With the merge-commit method, GitHub now creates one merge commit per pull request. Before, it created one for the whole group.
• Deleted base branches. GitHub retargets the stack automatically instead of closing the bottom pull request. This supports workflows where one stack branches off another.
• Auto-merge. Stacks can be set to merge once the repository's requirements are met. GitHub says this is rolling out over the next few weeks, so don't assume it is on for your account today.
• Navigation and visibility. Stack details now sit in the pull request page's persistent header and in the pull requests list view. Shift+J and Shift+K move between pull requests in a stack.
• Lifecycle events and webhooks. The timeline shows when a pull request is added to or removed from a stack. The pull_request webhook gains a stacked action when a pull request joins a stack.
• CLI and agents. The gh stack extension for GitHub CLI now supports Git worktrees. GitHub also cites faster initialization, checkout and navigation.

How merging works​

These details come from GitHub's merge documentation.

• Bottom-up only. You can merge any contiguous group that starts at the lowest unmerged pull request. A mid-stack pull request can't merge on its own, because everything below it merges with it.
• Requirements. All lower pull requests must be approved and have passing checks. The stack must have a linear history, and the pull request must meet the branch protections for the stack base.
• Non-linear stacks. If a lower branch changed or the trunk moved ahead, a Rebase stack button appears in the merge box.
• After a partial merge. The next unmerged pull request is automatically rebased to target the base directly.
• Merge queues. Pull requests enter the queue in order. If one is ejected, everything above it is removed too. The queue may exceed its configured maximum group size by up to 50% to keep a stack together. A stack too big for that buffer goes into the next merge group as a single unit.

The merge documentation retrieved during research still says auto-merge is not supported for stacks. That conflicts with the GA changelog. The likely explanation is that the docs haven't caught up with the staged rollout. Treat the changelog as the newer statement, and check your own repository before relying on it.

Automation and API notes​

GitHub's async merge API, which went GA on October 1, is now the recommended way to merge pull requests programmatically. It is also the only merge API that supports stacked pull requests. Scripts that call the legacy synchronous merge endpoints or GraphQL mutations can't merge a stack.

GitHub's API documentation adds several details:

• The merge runs in the background, and callers poll for the result.
• Branch protection and repository rules are evaluated when the merge actually runs. A rule failure shows up as a failed result while polling.
• A stack merge request is atomic. The whole group merges or is queued, or none of it is.
• The REST API can read and manage stacks. GraphQL is read-only for them.

The CLI docs add a few more points:

• gh stack merge is all-or-nothing.
• Branch protection is evaluated at merge time, and any failure is reported back.
• If the base branch uses a merge queue, the queue chooses the merge method.
• The CLI reference notes that merge requirements can't be bypassed through the CLI. The changelog says bypass permissions now apply to stacks, so check the CLI's behavior yourself before relying on bypass there.

Limits to check first​

• Same repository only. Cross-fork stacks aren't supported. The roll-out guide also says stacks can't include forks or branching structures. Teams that depend on fork-based contributions should keep that work outside stacks.
• No GitHub Desktop. Support is listed for the website, GitHub CLI, GitHub Mobile, webhooks, REST, GraphQL and an agent skill.
• Merge-method caveat. One third-party summary of the preview, from AlphaSignal, advises repositories that default to squash or rebase merging to consider merge commits. It says stack identity tracking can break otherwise. GitHub's docs say stacks support all three merge methods, so test this on a non-critical repository.
• Enterprise Server. GA applies to github.com plans. GitHub says only that the feature will be in an upcoming GitHub Enterprise Server release, with no version or date.
• Docs still say preview. Some GitHub guides retrieved during research still carry public-preview notices. The dated changelog is the authority for the GA claim.

Reading GitHub's numbers​

GitHub says that since the preview began, repositories using stacks saw a 9% increase in merged code compared with peers. It also says over two-thirds of the top 1% of repositories now use stacks and saw a 5% improvement in time-to-merge.

These are GitHub's own figures. The announcement gives no measurement period, sample size or definition of "peers". Heavy users of any new workflow tend to be the busiest teams anyway, so cause and effect is unproven. Merged code volume is also not the same as quality.

Practical impact​

The most useful changes for enterprise admins are the ones that stop stacks from fighting repository rules. Approvals that survive a rebase, signed replacement commits and per-pull-request merge commits all keep the audit trail intact. Teams with strict compliance rules were the likeliest to be blocked by earlier behavior.

Developers who use third-party stacking tools should compare them against the native version. Their mechanics now overlap with GitHub's. A DEV Community write-up argues the native feature covers the core mechanics. It says third-party tools still differ on polish, cross-repo workflows and team features. That is one commentator's view.

A cautious way to start:

1. Try a small stack on a low-risk repository with your real branch protections.
2. Confirm that CODEOWNERS and required checks behave as you expect on mid-stack pull requests.
3. If you use a merge queue, check how a stack sits in it.
4. Update any merge scripts to use the async merge API.
5. Wait for auto-merge to reach your account before building a workflow around it.