GitHub puts stacked pull requests into public preview

GitHub has put stacked pull requests into public preview, with the feature rolling out across all repositories.

The update gives developers a native way to split a large code change into a sequence of smaller pull requests that can be reviewed separately. Each pull request sits within an ordered stack, showing reviewers where that change belongs in the broader set of work.

Until now, teams using this approach on GitHub often relied on external tools or manual branch management. The new option is built into the existing pull request workflow and works with current review rules, checks, and merge requirements.

A stack map appears at the top of each pull request, showing how one layer relates to the others above and below it. When reviewers open an item in the sequence, GitHub shows only the diff for that layer rather than the full set of changes across the stack.

The design addresses a common problem for software teams handling large or interdependent updates. A single broad pull request can be slow to assess, while multiple linked branches can create extra maintenance work as code changes beneath them.

Teams can review different layers in parallel and merge a stack in more than one way. If the highest ready pull request is merged, the platform also merges every unmerged layer beneath it in one operation. Teams can also merge only the lower layers, leaving pull requests above them open while GitHub automatically rebases and retargets them.

GitHub is also offering a command-line extension, gh-stack, to create and manage stacks. Developers can use the feature through GitHub on the web, the GitHub CLI, the GitHub mobile app, and coding agents including GitHub Copilot through the gh-stack skill.

Review pressure

The launch comes as software companies look for ways to manage a growing volume of code produced with AI tools. Code generation has sped up, but review has become a point of friction for many engineering teams because every change still needs checks, approvals, and context.

GitHub pointed to several early users that tested the workflow in production, including Whoop, Vercel, TED, and jQuery. Their comments suggest stacked pull requests are being positioned as a response to review bottlenecks rather than simply another branching option.

One customer comment focused on the effect on larger projects moving through review. "The feature has helped the team ship larger work through smaller, more reviewable changes," said the Next.js Lead at Vercel.

Another early user highlighted the effect on merge management for grouped changes. "The merge queue experience for stacks is a major friction-reducer," said the Creator of jQuery.

TED linked the feature to the changing pace of software development inside teams using AI assistance. "Stacked PRs addressed a review bottleneck created by AI-driven productivity gains, tightening the team's feedback loop," said the Chief Technology Officer at TED.

Whoop described a shift away from oversized pull requests toward smaller linked reviews inside GitHub itself. "The shift from unwieldy single PRs to reviewable stacks makes the feature feel native to GitHub itself," said an Engineer at Whoop.

Native workflow

For GitHub, the release expands the pull request model at the center of its developer platform without requiring teams to adopt a separate review product. That may matter for organizations that want tighter review workflows without retraining developers on external systems or changing branch protection settings.

Existing branch protections and required checks still govern what reaches the main branch. That means teams using the new structure can apply the same controls they already use for standard pull requests while handling multi-step changes in smaller units.

Support for merge queues with stacked pull requests is being added progressively. Each layer can still be reviewed independently, while the broader sequence remains visible in the stack map.

The result is a native GitHub workflow designed to make large changes easier to inspect, approve, and merge without treating each pull request in isolation.