Stacked PRs are now live on GitHub

Original Article ↗ Hacker News Discussion ↗

GitHub’s new stacked pull requests feature, now in public preview, aims to help developers break large code changes into a series of smaller, dependent PRs that can be reviewed and merged more easily. Many engineers welcome native support for a workflow they previously emulated with third‑party tools or manual branching, noting benefits for CI, review scope, and parallel work. Others argue the feature is incomplete, buggy, or redundant with well‑structured commits, and some criticize GitHub for ignoring prior art in systems like Gerrit and Phabricator or for shipping another layer of complexity instead of improving core review tooling.

Overall Reception

  • Many are excited; stacked PRs are described as one of GitHub’s biggest changes in years and a long-missing feature compared to other systems.
  • Others are underwhelmed, calling it mostly “UI sugar” over patterns they already used (PRs targeting other PR branches).
  • Some think it’s late and basic/buggy for a v1; others are just glad it’s not another AI feature.

Perceived Workflow Benefits

  • Lets large features be split into smaller, reviewable units while work continues on later parts.
  • Enables parallel review: refactor → backend → frontend, with different reviewers per layer.
  • Supports merging subsets of a feature stack (e.g., infra + API but not UI) and running CI per unit.
  • Stack management (auto-rebasing dependent PRs, merge-one-or-merge-all) is seen as a big win versus manual rebasing.

Critiques and Limitations

  • Some see stacked PRs as a band-aid for organizational/review problems; they argue for better commit hygiene and smaller, independent PRs instead.
  • Concerns that stacking increases complexity, encourages long-lived branches, and adds pressure on reviewers (“changing the bottom of a 5-deep stack is painful”).
  • Current implementation has bugs, especially around squash merging stacks and merge-queue interactions; cross-repo and full fork support are still missing.
  • Several say this doesn’t solve the hard parts: reordering messy local work into coherent series, true cross-repo stacks, or trees/graphs of dependent changes.

Review & UI Concerns

  • GitHub’s unit of review is still the PR; commit-by-commit review is awkward, and comments don’t map cleanly to evolving commits.
  • Some wish GitHub had adopted a diff/patch-series model with change IDs and interdiffs, like Gerrit/Phabricator and big internal forges.
  • The web UI for stacks is viewed as minimal; serious users expect to rely on CLI or custom tooling.

AI and Broader Context

  • Multiple comments tie stacked PRs to growing AI-generated diff sizes and agent workflows, as a way to keep reviews human-scale.
  • Others stress stacked workflows long predate AI; this feature mainly mainstreams an established practice.