GitHub Stacked PRs

Original Article ↗ Hacker News Discussion ↗

GitHub is introducing “stacked PRs,” a way to break large, dependent changes into a chain of smaller pull requests that can be reviewed and merged in order, more closely mirroring workflows from tools like Gerrit and Phabricator. Commenters welcome the native UI support for managing complex changes in big codebases and AI-assisted workflows, but disagree on whether this solves fundamental review and git-UX problems or just adds another abstraction, noting gaps such as weak cross-repo support, limitations with forks, and reliance on GitHub’s CLI.

What stacked PRs provide

  • Feature lets you create a chain of dependent PRs so each represents a small, “reviewable” unit while depending on earlier ones.
  • Reviewers can focus on subsets of a large change, with CI, discussion, and approvals scoped per PR rather than one giant diff.
  • GitHub adds a stack-aware UI and (via gh stack) automation for rebasing, syncing, and merging multiple PRs together or in order.

Typical use cases described

  • Large refactors or framework upgrades (e.g., language/React Native/Angular version bumps) that touch many files.
  • Backend–frontend feature work where the backend can land independently but the frontend depends on it.
  • Long-running features in monorepos, where many small, incremental changes are preferable to a single huge branch.
  • Less helpful for cross-repo or cross-microservice work; several people want stacks across multiple repositories but GitHub does not support this.

How this differs from existing Git/GitHub workflows

  • Many commenters already emulate stacked PRs using branched chains, git rebase --update-refs, and manual PR creation.
  • Key improvement is first-class UI and coordination: seeing the stack, merging multiple levels at once, and having GitHub rebase children when parents merge.
  • Some argue GitHub should instead improve per-commit review, interdiffs, and interactive history editing in the UI.

Comparisons with other tools and workflows

  • Frequently compared to Phabricator and Gerrit “stacked diffs,” which many consider superior to GitHub’s traditional PR model.
  • GitLab has “stacked diffs” and merge trains; people contrast UIs and limitations.
  • Other stacking tools mentioned: Graphite (now part of Cursor), Tangled.org + jujutsu, Sapling, git-town, git-spice.
  • Broader side-thread on Git vs Mercurial performance, UX, and big-tech internal systems (Sapling, Piper, etc.).

Limitations and open questions

  • Currently single-repo only; not supported across forks or multiple repositories.
  • Unclear how well review history survives rebases/restacks and how robust conflict handling is beyond “stop and fix.”
  • Some worry about long-lived stacks, rebase/force-push footguns, and merge-conflict complexity, especially with squash merges.

Philosophical disagreements

  • Supporters: stacked PRs make large work tractable, reviews faster, and encourage small, semantically meaningful units.
  • Skeptics: prefer simple branches + small independent PRs, or see stacks as compensating for poor GitHub review UX rather than a fundamental need.
  • Debate over whether the “atomic” unit should be a commit, a PR, or an email-style patch, and whether partial stack merges are architecturally sound.