GitHub Stacked PRs、pull request UIにnativeなstack workflowを持ち込む

GitHubが出してきたもの

GitHubはGitHub Stacked PRsのprivate previewを公開し、大きな変更を相互依存する小さなpull requestの連鎖へ分解するworkflowを提示した。GitHubのモデルでは、各PRはすぐにdefault branchを向くのではなく、一つ下のbranchをbaseにする。gh stack CLIがbranch作成、push、rebase、PR提出を担当し、pull request UIはstack mapを表示してreviewerがlayer間を移動しても文脈を失いにくくする。

製品メッセージは明快だ。大きなdiffはreviewが遅くなり、流れを壊しやすい。GitHubはfeatureを小さく順序づけられた単位に分けることで、review commentを局所化し、段階的にmergeし、「巨大なPR一つが周囲すべてを止める」状況を減らそうとしている。

なぜエンジニアが注目したのか

今回のHacker News議論で重要だったのは、GitHubがstacked developmentを外部ツールの慣行としてではなく、core PR systemの一級機能として扱おうとしている点だ。preview文書によれば、branch protection ruleはdirect base branchだけでなく最終target branchに対して評価される。CIもstack内の各PRを最終branch向けであるかのように実行する。これは、中間PRはgreenでも最終mergeでは壊れるという、自前stack workflowの大きな穴を塞ぐ方向だ。

GitHubはstack全体でも一部だけでもmergeでき、merge後は残ったPRが自動rebaseされて、最下段の未merge PRが正しいbranchを指すようになるとしている。すでにGraphiteやMetaの古いghstackに慣れたチームにとって大きいのは、発想そのものより、その発想がGitHub native UIとmerge flowへ入ってきたことだ。

次に見るべき点

まだprivate previewなので、厳しいbranch protection、merge queue、複数チームのreview習慣の中でどこまで安定して動くかが本当の試金石になる。それでも今回の公開は、GitHubがstacked changeをexpertだけの回避策ではなく、mainstreamなreview patternとして見始めたことを示している。文書にnpx skills add github/gh-stackによるAI agent integration経路まで含まれているのも興味深い。GitHubがhumanだけでなくcoding agentもstackを作り、たどり、維持することを日常的な開発フローとして想定しているからだ。