Hacker Newsが好感したGitHubの stacked PR、巨大diffを小さくレビューする方向へ

Hacker NewsでGitHub Stacked PRsがすぐ話題になったのは、解決しようとしている問題があまりに身近だからだ。大きい pull request は review が遅くなり、feedback の往復で branch が汚れ、rebase のコストも重くなる。GitHubの overview では、stack を「互いに積み上がる小さな PR の列」として説明している。各 layer は独立してレビューできるが、最終的には一つの大きな変更として着地できる。体験の中心は GitHub UI と gh stack CLI の組み合わせだ。

面白いのは GitHub が stack を end-to-end で理解させようとしている点だ。各 PR は直下の branch を base にしつつ、branch protection と CI は最終 target branch に対して評価される。reviewer は stack map で層を行き来でき、author は cascading rebase をまとめて走らせられる。さらに merge は stack 全体だけでなく一部の layer だけでも進められ、下の PR が入ったあと残りの PR は自動で base が更新される。ここが単なる branch naming rule との違いだ。

• 機能は private preview で、ネイティブ UI と gh stack CLI がセットになっている。
• GitHubは大きな変更を小さな review surface に分けることを前面に出している。
• AI coding agent 向け integration まで最初から触れている。

community discussion noted 歓迎一色ではなかった。HNでは「これは monorepo や大規模 refactor にかなり合う」という声がある一方で、複数 repo にまたがる依存関係も扱いたいという要望がすぐ出た。また「最初から commit をもっと小さく切ればいい」という皮肉も目立ったが、実務では commit の単位、review の単位、merge の単位がきれいに一致しないことが多い。だからこそ stack 専用の道具が必要になる。

結局 GitHub が狙っているのは、良い review hygiene を“気合い”ではなく product で支えることだ。派手な新機能というより、巨大 diff をそのまま投げ込まずに済むようにするための土台に近い。Hacker Newsがここに反応したのも、毎週どこかで詰まる code review のボトルネックを GitHub がやっと本気で product 化し始めたと見えたからだ。