GitHub brings stacked pull requests out of preview

GitHub announced the general availability of stacked pull requests on October 6, 2026, making the feature available across all github.com plans. Stacks let developers divide a large change into smaller pull requests, review the pieces separately and merge them together.

Two parts of the announcement remained on a longer timetable. GitHub said stack auto-merge would roll out over the following few weeks, allowing selected pull requests to merge together once all meet the repository’s requirements. Support for GitHub Enterprise Server was promised for an upcoming release.

The rebase changes focus on preserving review work. When an otherwise unchanged stack is rebased after its base branch advances, GitHub says approvals stay in place—even in repositories configured to dismiss stale approvals. The Rebase stack operation also creates signed replacement commits while preserving the original authorship.

At merge time, a stack moves through the merge queue as one group. That does not mean it leaves just one merge commit: when the merge-commit method is used, GitHub creates a separate merge commit for each pull request. The release also handles a branching-stack problem: deleting a stack’s base branch now causes GitHub to redirect the stack to another base rather than close its bottom pull request.

Navigation and local workflows get smaller changes. Stack details remain visible in the pull request page’s persistent header, and Shift+J and Shift+K move between pull requests in a stack. For developers working locally, the GitHub CLI’s gh stack extension adds Git worktree support, alongside changes to initialization, checkout and navigation.