On Tuesday, October 6, 2026, GitHub announced in its official changelog that stacked pull requests are now generally available. The feature lets teams split a large change into a chain of smaller, focused pull requests that can be reviewed independently and merged together. It is available on all github.com plans and will come to GitHub Enterprise Server in an upcoming release.
A stack consists of two or more pull requests in the same repository. The first, at the bottom, targets the trunk branch, usually the project's default branch. Each subsequent pull request targets the branch of the one below it. According to GitHub's documentation, foundational changes such as shared types or database schemas go in the lower layers, and code that depends on them, such as API routes or interface components, goes in the higher ones.
The main advantage is not having to wait. With a stack, a developer can open a new pull request on top of one that is still open instead of waiting for it to merge. Each layer shows only its own diff, so reviewers see small changes rather than one big pull request. GitHub argues that small reviews are faster, are read more carefully and are less likely to go stale and pile up conflicts.
The company explicitly ties the feature to AI. The documentation explains that when a lot of code is generated at once, often with AI agents, a stack gives each change its own place: an agent completes one task and starts the next one that builds on it, which fits the pattern of “one pull request per task, each based on the one below.” That way, dependencies are recorded explicitly rather than mixing changes into a single branch.
GitHub shared figures from the public preview. According to the company, repositories using stacks merged 9% more code than comparable repositories, and more than two-thirds of the top 1% of repositories now use stacked pull requests, with a 5% improvement in time to merge. These are the vendor's own numbers, without external audit, but they point to notable adoption among the most active projects.
The general availability release changes how merging and rebasing work. When an otherwise unchanged stack is updated because its base branch moved ahead, the Rebase stack option now preserves approvals, even in repositories that dismiss stale approvals. During that process, GitHub creates signed replacement commits that preserve original authorship, and users with permission to bypass repository rules can use it to merge the lowest unmerged pull request.
Merge queue integration also improves: a stack now enters and lands through the merge queue as a single group, and with the merge commit method GitHub creates one commit per pull request instead of one for the whole group. If a stack's base branch is deleted, GitHub automatically retargets the stack instead of closing its bottom pull request. Auto-merge for stacks will roll out over the next few weeks.
Navigation changes too. Stack information is always shown in the persistent header of each pull request page, and the Shift+J and Shift+K keyboard shortcuts let users jump between layers. The timeline records when a pull request joins or leaves a stack, and the pull_request webhook now includes a “stacked” action. The gh stack extension for GitHub CLI supports Git worktrees and is faster at initialization, checkout and navigation.
There is a dedicated path for agents. Besides the extension, which is installed with gh extension install github/gh-stack, GitHub offers an agent skill, gh-stack, installed with gh skill install github/gh-stack. The CLI includes commands to initialize a stack, add layers, push them, submit them, view them, sync them, rebase them and merge them, and the REST and GraphQL APIs expose each pull request's stack membership.
Quality rules apply to the whole chain. Merge requirements are determined by the base branch of the bottom pull request, and branch protection rules, such as code owner approvals, are enforced on every pull request in the stack, even mid-stack ones that do not target the default branch directly. Continuous integration checks for the default branch also run on every layer, not just the bottom one.
There are limits. Stacks must merge from the bottom up: merging the top pull request merges everything below it, and merging a mid-stack one brings the lower ones along while the higher ones retarget the base. All branches must be in the same repository, so cross-fork stacks are not supported, and the feature is not available in GitHub Desktop. Anyone merging through the API must use the asynchronous merge API for stacks.
Early users are enthusiastic. “It took one merge with GitHub's Stacked PRs for me to conclude that it's amazing,” said Charlie Marsh, founder of Astral, as quoted by GitHub. David Mostoller, a software engineer at Comcast, said that seeing every branch of the stack in the interface, checking its status and navigating between them makes managing and reviewing many dependent pull requests far easier for a team.
The context helps explain why GitHub stresses the AI angle. As coding agents produce more code, the bottleneck shifts toward human review. A large pull request generated by an agent is hard to evaluate; a series of small, ordered changes, each with its own validation, fits better with the oversight teams require. Stacks do not solve code quality, but they do bring order to its review.
In conclusion, the general availability of stacked pull requests turns into a native feature a practice many teams already followed with external tools. The improvements to approvals, signing, the merge queue and automation reduce friction, and agent support shows where software development is heading. The key will be for teams to use stacks to review better, not just to merge faster.
