GitHub Ships Stacked Pull Requests so Developers Stop Rebasing Branches Manually

GitHub's native stacked PRs hit public preview, letting teams split large changes into reviewable layers that merge in one click without manual rebasing

Microsoft DeveloperMicrosoft Developer
·
·
AuthorBy AlphaSignal Newsroom
Read4 min
TypeNews
TopicDevelopment · Api
SubtopicCode Review
  • Public preview live: GitHub stacked pull requests are now available to all repositories with no waitlist or paid plan required.
  • One-command setup: Install via gh extension install github/gh-stack and create your first stack in under a minute.
  • Auto-rebasing: GitHub handles cascading server-side rebases automatically when a layer merges, eliminating the biggest pain point of manual stacked workflows.
  • Full CI and branch protection: Every layer in the stack runs the same checks and enforces the same rules as a direct PR to main.
  • Squash/rebase merge caveat: Repos configured to squash or rebase merge by default should switch to merge commits to avoid stack identity tracking breaking.
  • Merge queue support pending: Merge queue integration is rolling out progressively over the coming weeks, not all at once.

GitHub just shipped something developers have been hacking around for years. Stacked pull requests are now in public preview, available to every repository with no waitlist, no enterprise plan, and no third-party tooling required. One CLI extension install and you're in.

The rebase tax, abolished

If you've ever shipped a large feature on GitHub, you know the two bad options: open one giant PR that nobody wants to review, or split it into dependent branches and spend your evenings manually rebasing five branches in the right order every time main moves. One produces a PR too large to review meaningfully; the other produces a maintenance burden that compounds with every upstream change.

Stacking PRs is an old idea. Facebook engineers had it since 2007 via Phabricator, and tools like Graphite built entire businesses around bringing it to GitHub. The difference now is that it's first-party. Reviewers need nothing installed, no third-party account, no browser extension. The stack lives inside GitHub itself.

How it works

A stack is two or more pull requests in the same repository, where the bottom PR targets the trunk (usually main) and each subsequent PR targets the branch of the PR below it. Foundational changes go at the bottom; code that depends on them, such as API routes or UI components, goes higher up.

A concrete example of the branch structure:

less
┌── feat/frontend      → PR #3 (base: feat/api-endpoints)  ← top
┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)
┌── feat/auth-layer    → PR #1 (base: main)                ← bottom
main

The mechanics that make this usable in practice:

  • Stack map UI: Reviewers see only the diff for their layer, with a stack map in the GitHub UI showing the full chain and one-click navigation between layers.
  • Automatic server-side rebasing: When you merge a PR at the bottom of the stack, the remaining branches are automatically rebased so the next PR targets the default base branch. No manual intervention needed.
  • CI runs on every layer: Branch protection rules including CODEOWNER approvals are enforced on every PR in the stack, even mid-stack PRs that don't directly target main. CI checks triggered by your default branch run for all layers, not just the bottom one.
  • Flexible merging: You can review and check each pull request independently, then merge everything in one click, or merge partway through. PRs above automatically re-target the base branch and stay open.
  • Agent support: The gh-stack skill lets GitHub Copilot and other coding agents create and manage stacks directly.

Where it shines, and where to watch out

The timing is deliberate. When an AI agent generates a large batch of code, a stack gives each logical task its own PR (database schema, then API, then UI) instead of dumping everything into one branch. The CTO of TED noted that AI had made their developers dramatically more productive but created a new bottleneck: PRs were growing large enough that reviewers were struggling. Tim Neutkens, the Next.js lead at Vercel, reported that stacked PRs helped introduce smaller individual changes while shipping larger features, making each PR faster to review.

A few rough edges worth knowing before you commit your team to the workflow:

  • Squash/rebase merge conflict: If your repository is configured to squash-merge or rebase-merge PRs by default, stack identity tracking breaks after the first merge. The workaround is gh stack rebase, but the cleaner fix is switching affected repositories to merge commits for stacked workflows.
  • Merge queue support is still rolling out: The public preview is available to all repositories now, but merge queue support is rolling out progressively over the coming weeks.
  • No cross-fork stacks: All branches in a stack must live in the same repository.
  • GitHub Desktop excluded: The feature is available on the web, CLI, and mobile, but not GitHub Desktop.

Get started in under a minute

Install the CLI extension, create branches in dependency order, then push and open linked PRs:

cpp
gh extension install github/gh-stack
gh stack create feat/auth-layer
gh stack create feat/api-endpoints
gh stack push
gh stack submit

The feature is also accessible from github.com, the GitHub mobile app, and programmatically via Webhooks, REST, and GraphQL APIs for teams that want to wire stacks into their own dashboards or automation. For teams that have been holding stacked workflows together with Graphite, custom scripts, or manual rebasing, this replaces all of that with zero setup on the reviewer's side. Read the official docs or join the feedback discussion to share what you find.

Comments

avatar