GitHubの『Stacked PRs』完全攻略：巨大なプルリクを卒業して開発スピードを爆上げしよう

GitHubでの「Stacked PRs（スタックPR）」は、依存関係のある複数の変更を小さなプルリクエストとして積み重ねる（スタックする）開発手法です。一つの巨大なPRを出してレビューを停滞させる代わりに、論理的な単位で分割して順次レビューを受けることで、レビューの負荷を減らし、マージ時のコンフリクトも最小限に抑えることができます。大規模開発や高速なデプロイサイクルを目指すモダンなチームにとって、今や必須と言える効率化テクニックです。

ついに来たか！GitHubのデフォルトだった「1つのPR＝1つのブランチ」っていうモデル、ずっとしっくりきてなかったんだよね。PhabricatorやGerritみたいなスタック型のコミット（Stacked commits）の方が、変更を考えるときの自分の思考プロセスに合ってるんだ。このオプションが追加されて嬉しいよ。例のCLIツールを入れなきゃな。

PhabricatorやMercurialを使ってた人間からすると、GitHubとgitをまた使うのは石器時代に戻ったような気分なんだ。これとjujutsu（jj）で、Phabricatorみたいなスタック型のデフ（stacked-diff）フローが再現できるといいな。これ、モノレポだけにいいわけじゃなくて、長期間にわたる機能開発でもレビューや作業がめちゃくちゃ楽になるんだよね。PRやデフを小さく保てるから、ビルドの合間にサクッとレビューできるし（デカいPRだとそれだけで時間を食うからね）。

個人開発者だとスタック型PRが必要になることは滅多にないけど、PRを小さくしてレビューしやすく保つっていう根本的な問題は、自分一人でレビューする場合でも重要。結局、後からデカいブランチを分割するんじゃなくて、作業前に小さなブランチに分けるよう自分を律するのが本質的な規律なんだよね。ツールはその手間を減らしてくれるだけ。AIアシストのワークフローに何か変化があるかも気になる。今はClaude Codeに機能ブランチを作らせてて、自然と一つの大きなデフになっちゃうけど、エージェントが自分の仕事を論理的なまとまりに分割できるようになったら、スタック型PRは面白そう。

何か見落としてるかもしれないけど、俺が必要なのは「スタック型PR」じゃなくて、個別のコミットをちゃんと管理できるUIとインターフェースなんだ。準備ができた一部のコミットだけを独立してマージしたり、レビュー済みマークを付けたり、対話的なリベース（interactive rebase）やコミットの統合・編集ができるUIが欲しい。コマンドラインならうまくできるけど、GitHubのUIじゃ無理だし、チーム全員がCLIに詳しいわけじゃないからね。特定のコミットやコミットメッセージにコメントできる機能や、force-pushのたびに何が変わったかを可視化する機能（diff of diff）も必要。Git自体にコミットの概念があるのに、なんでその上に「スタック型PR」なんて抽象化を重ねるんだろう？何か見えてないメリットがあるのかな。

スタック型PRに特化したGraphiteっていうスタートアップがあるよね。しばらくそこを使ってるけど、なんでGitHubが似たような機能を実装しないのかずっと不思議だった。完璧に動くなら、GitHubに乗り換えてみようかな。

これで「Squash & Merge」のUXの問題は解決するのかな？今は手動でスタック型PRをやってるんだけど、例えば main <- PR A <- PR B <- PR C みたいに繋いで、もしPR Bが先にマージされたら、PR Aをmainにマージするのは問題ない。でも、PR Aが先にmainにマージされると、PR Bを直すのが悪夢なんだ。GitHubのUIが自動的にターゲットブランチをmainに変えちゃうんだけど、そこから突然コンフリクトが湧いてくる。リベースしようとすると、なぜか関係ない変更まで全部手動で確認させられるし（理由はわかる、PR Aをマージしたことでmainの先頭に新しいマージコミットができて、gitがそれをうまく扱えないとかそういうやつでしょ）。だから、新しいUIが欲しいんじゃなくて、1998年にリベースの教典を指先から授けたリナスとかじゃない普通の人にとっても、ただ「ちゃんと動く」ツールが欲しいんだよ。

スタック型PRの意義がいまいち分からないな。普通にgitを使えばパッチセットを送れるし、それを個別にレビューしたりテストしたり適用したりできるでしょ。PRのワークフローだと、パッチシリーズが分割不能な変更セットになっちゃって、一括でレビューやテストをしなきゃいけなくなる。スタック型PRはその問題を回避しようとしてるんだろうけど、そもそもPRの実装の仕方が問題なんだよね。本当に必要なのは、一塊のバンドルじゃなくて、個別のコミットやパッチをまたレビューできるようにすること。スタック型PRは、最初の抽象化レイヤーの問題を回避するための、二重の抽象化レイヤーに見えるよ。

スタック型PRは大好きだけど、この実装方法はなんだか変な感じがする。ただ各ブランチがチェーンの中の親を指すようにすればいいだけじゃん。ネイティブなGitそのままでさ。GitHubがこれをもっとサポートしてくれるのをずっと待ってたけど、CLIじゃなくてUIでのサポートが欲しいんだよね。

GitLabの glab stack と違って、GitHubがUIにちゃんとスタックを組み込んできたのはすごくいいね。ただ、マージの設定がちょっと違和感ありそう。つまり、スタックの一番下をマージしたら、残りのスタックがリベースされて、それがCIのテスト実行を走らせちゃうよね。3つのパッチがスタックにあって、下の2つをマージしたい場合、1つ目をマージして、2つ目のテストが終わるのを待ってからまたマージする…って感じになるのかな？一気に2つマージするんじゃなくて。まあ実際に使ってみないと、restackingとかでどうにかなるのかは分からないけど。

gitを使ってる人には gh stack CLIは必須になりそうだけど、jjやsl（Sapling）を使ってる人もスタックを扱えるように、強制されないといいな。インターフェースとして gs submit や gs push があるのはいいけど、 gs init や gs add はオプショナルであるべきだよ。