Hacker News Likes GitHub’s Bet on Smaller, Stackable PRs

Hacker News reacted fast to GitHub Stacked PRs because the problem statement barely needs selling. Large pull requests are slow to review, easy to stall, and expensive to rebase once feedback starts piling up. GitHub’s new overview frames stacks as a way to break one large change into a sequence of focused PRs that build on each other. Each layer stays reviewable on its own, but the whole stack still lands as one coherent body of work. The product surface is split between native GitHub UI support and a new gh stack CLI for local workflow.

The interesting part is how deeply GitHub wants stack awareness to run. In the docs, each PR in a stack targets the branch below it, yet branch protection and CI are evaluated against the final target branch, not just the immediate base. Reviewers get a stack map, authors can trigger cascading rebases, and teams can merge one layer, several bottom layers, or the whole stack. When part of the stack lands, the remaining PRs are rebased automatically so the chain stays valid instead of collapsing into manual branch surgery.

• The feature is in private preview and tied to native GitHub UI plus the gh stack CLI.
• GitHub explicitly positions stacks as a way to keep diffs small without losing overall context.
• The product page also calls out AI agent integration, not just human author workflow.

community discussion noted that the idea is attractive partly because it formalizes a workflow many teams already approximate by hand. HN commenters immediately split into camps: one group saw strong monorepo and long-lived refactor use cases, while another asked for support across multiple repositories with ordered dependencies. There was also the predictable “just make smaller commits” skepticism, but that criticism misses the point a bit. Commits, review units, and merge units are related, not identical, and most production teams feel that gap every week.

That is what makes the announcement more than a UI nicety. GitHub is trying to lower the operational cost of good review hygiene instead of relying on every team to invent its own stack conventions. If the preview works well, the win is not flashy. It is that a big change can move through review as a set of small, comprehensible layers without losing CI guarantees or turning rebases into a tax humans pay by hand.