GitHub Stacked PRs

Original Article ↗ Hacker News Discussion ↗

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.