gh skill install github/gh-stack で学習させられるGitHubが公開した GitHub Stacked PRs は、ひと言でいうと「でかい変更を、小さく切って順番にレビューできるようにする仕組み」です。
これ、地味に見えてかなり重要です。
というのも、大きなPRってレビューする側にとってかなりつらいんですよね。差分が多すぎてどこを見ればいいか分からないし、少し直しただけで別の場所にも影響が出るし、時間が経つとコンテキストも飛ぶ。結果としてレビュー品質が落ちて、チーム全体の速度も落ちやすい。
そこで出てくるのが stacked PRs。
変更を「1本の巨大なPR」ではなく、複数の小さなPRの連なりとして扱います。各PRはそれぞれ独立してレビューしやすいサイズにして、最後はまとめて本流のブランチに入れる、という考え方です。
個人的には、これはGitの世界でずっと“できる人はやっていた”テクニックが、ついにGitHubの正式な体験として整ってきた、という印象があります。かなり嬉しい進化ではないでしょうか。
元記事では、stack をこう説明しています。
main に着地するつまり、こんな感じです。
main ← PR #1 · auth-layer ← PR #2 · api-endpoints ← PR #3 · frontend
下のPRが土台で、その上に次の変更を積んでいくイメージです。
ここがポイントで、上のPRは下のPRの変更を前提にしているので、順番に意味があるんですね。
普通のPRだと「このPR単体で完成していること」が理想ですが、Stacked PRsでは「小さな完成品を順番に積む」感じです。
この発想は、複雑な機能開発ほど効いてきそうです。認証、API、フロントエンドみたいに層が分かれている作業には、かなり相性がよさそうだと思います。
この機能の良いところは、ただの運用ルールではなく、GitHub自体がスタックを理解してくれる点です。
元記事によると、GitHubはスタックをエンドツーエンドで扱います。具体的には：
これ、かなり大事です。
なぜなら、stacked PRs は「工夫すればできる」だけだと、実運用で面倒になりがちだからです。GitHubがUI・ルール・CIまで含めて面倒を見てくれるなら、チームに導入しやすい。
特にレビュー画面で、今見ているPRが全体のどこにあるのか分かるのは大きいです。
スタック型の開発は便利ですが、油断すると「このPRってどこまでが前提だっけ？」と迷子になりやすいので、可視化はかなり本質的だと思います。
元記事が強く押している理由はシンプルで、大きなPRは扱いづらいからです。
小さいPRなら、レビューする人は変更意図を追いやすいです。
「これは認証の変更」「これはAPI追加」「これはUI調整」と、役割が分かれれば、コメントも的確になります。
変更を長期間ため込むほど、他の人の作業とぶつかりやすくなります。
Stacked PRsでは、下の層から順に積み上げるので、早い段階で変更を分離しやすい。結果として、衝突のダメージを抑えられる可能性があります。
大きなPRが1本あると、レビュー待ちで止まりやすい。
でも小さいPRが連なっていれば、先頭から順にレビューを進めやすいし、必要なら一部だけ先にマージすることもできる。これ、地味ですが開発体験に効きます。
個人的には、「チームの速度を上げる」と聞くと新機能をどんどん増やす話に見えがちですが、実際はレビュー負荷を下げることのほうが効くことが多いと思います。Stacked PRsはまさにそこを狙っている感じです。
元記事では、gh stack CLI が紹介されていますが、必須ではありません。
ここはかなり重要です。
Stacked PRs は次の方法で扱えます。
gh stack CLIつまり、「CLIを入れないと何もできない」という話ではありません。
チームの文化や好みに合わせて導入できるのは、かなり現実的です。新しい仕組みは、便利でも“専用手順だらけ”だと途端に広がりにくいので、これは良い設計だと思います。
gh stack CLI でできることCLIを使うと、ローカル作業がかなり楽になるようです。元記事によると、以下を支援します。
rebase は簡単にいうと、コミットの土台を付け替えて履歴を整える操作です。
Stacked PRsでは、下層の変更が動くと上層もずれていくので、連鎖的に整え直す必要があります。その面倒をCLIが肩代わりしてくれるわけです。
マージ時の柔軟さも、かなり面白いポイントです。
元記事では、以下が可能とされています。
さらに、たとえば「下の2つだけ先に入れたい」といった場合、そのレイヤーに対してCIが通るのを待てば、一度にマージできると説明されています。
これは実務上かなり便利そうです。
全部そろうまで待つのではなく、入れられるところから入れる。開発の現場では、こういう細かい融通が効くかどうかで使い勝手が全然違います。
そして、あるPRがマージされたあとには、残りのPRが自動でrebaseされるとのこと。
つまり、下の土台が更新されても、上のPRたちが追従してくれる。ここは「スタック」を名乗るだけあって、かなり筋が通っています。
元記事には、AI agent integration の話もあります。
gh skill install github/gh-stack を実行すると、AI coding agentsに stacks の扱い方を教えられるそうです。
これ、時代を感じます。
今後は人間だけでなく、AIにも「このリポジトリではこういうPRの積み方をする」と理解させる必要が出てくるわけです。
個人的には、AIが雑に大きな変更を投げるより、Stacked PRsのようなルールに従って小さく積む方向のほうが、現場ではずっと役に立つと思います。AIは便利ですが、レビュー不能な巨大差分を作られると結局困るので、こういう“運用の型”を渡せるのはかなり良いです。
ここは大事な注意点です。
GitHub Stacked PRs は現在 private preview です。
つまり、誰でも今すぐ自由に使える状態ではありません。
元記事でも、リポジトリで有効化されていないと機能しないと書かれています。
そのため、今の段階では
という流れになります。
新機能の初期段階としては自然ですが、実際に使いたい人はここで少し足止めされるかもしれません。
とはいえ、GitHubが本気でこの体験を整えに来ているのは伝わります。
GitHub Stacked PRs は、単なる新機能というより、大きな変更をどうやって安全に、速く、レビューしやすく扱うかという長年の課題に対する答えの1つだと思います。
特に良いのは、
「分割して積む」というアイデア自体は昔からあったけれど、それをGitHubのUI、ルール、CI、CLIまで含めて一貫した体験にしたことです。
大きな機能開発は避けられません。
でも、レビュー不能な巨大PRを毎回投げ合うのは、やっぱりしんどい。
そう考えると、Stacked PRs はかなり実用的で、チーム開発のストレスを減らしてくれそうだなと思います。
今後これが正式公開されたら、PR文化そのものが少し変わるかもしれません。
少なくとも、「大きいから仕方ない」で済ませる時代は、少しずつ終わりに向かっているのではないでしょうか。