GitHub Makes Stacked Pull Requests Generally Available

GitHub Makes Stacked Pull Requests Generally Available

GitHub made stacked pull requests generally available on October 6, adding stack-aware rebasing, bottom-up merging and automation to repositories that want to split one large change into dependent reviews. GitHub says repositories using stacks during preview merged 9% more code than peers, while participating repositories in the top 1% by activity saw a 5% improvement in time to merge.

The GA release changes more than navigation. Approvals can survive a stack rebase when the reviewed code is unchanged, GitHub signs replacement commits, and the platform retargets dependent pull requests as lower layers merge.

Dependencies are explicit, and merge order is constrained

A stacked pull request is based on another branch in the same stack rather than directly on the repository’s default branch. That lets reviewers inspect a database change, service change and interface change separately while preserving their dependency order.

Three-layer flow showing a stacked pull request merging from the base upward
Image: TVG Report.

GitHub requires the lowest unmerged pull request to land first. After that merge, the next pull request is retargeted so the stack can advance without presenting already-merged code as new work. Required checks, reviews and repository rules still apply at each layer; a stack is not a bypass around branch protection.

Rebase no longer discards unchanged approvals

When the base branch moves, the GA Rebase stack operation preserves approvals for code that did not change, even where a repository normally dismisses stale approvals. GitHub also creates signed replacement commits and preserves original authorship. Automatic rebases after partial merges sign replacements when branch rules require signatures or an original commit was signed.

Comparison of preserved approvals and signed replacement commits during a stack rebase
Image: TVG Report.

That distinction matters for audit trails. A rebase changes commit identities, but the new signatures and retained authorship make the platform-generated history distinguishable from an unsigned local rewrite. Review is preserved only for unchanged code; edited layers still need the checks and approvals required by repository policy.

CLI and webhooks move stacks beyond the browser

The GitHub CLI can create, submit, sync and merge stacks, while APIs and webhooks expose stack state to internal tooling. GitHub also added a repository-level toggle, enabled by default, so administrators can disable the feature where existing automation assumes every pull request targets the default branch directly.

Google’s independent engineering guidance favors small, self-contained changes because they are easier to review accurately and less likely to introduce defects. Stacks address the dependency problem that often makes that advice difficult to follow: each layer can stay focused without forcing unfinished prerequisites onto the default branch.

The operational limit is still the dependency chain. A failed check or requested change low in the stack can require rebasing the layers above it, so teams need CI that identifies the affected layer rather than rerunning unrelated validation blindly.

Sources

About TVG Editorial Team

TVG Report editorial coverage for robotics, AI, maker hardware, automation, and STEM technology.

View all posts by TVG Editorial Team →

Leave a Reply

Your email address will not be published. Required fields are marked *