スタックされたプルリクエストがGitHubで利用可能になりました

2026年7月31日原文(github.blog)

概要

Stacked Pull Requests （積み上げ型PR）は、大きな変更を小さく分割して段階的にレビュー可能
各PRは独立したレイヤーとなり、順序立ててマージやレビューが可能
GitHub組み込み機能でCLIやWebから簡単に操作・管理
チームの生産性向上、レビュー効率化、品質維持に貢献
パブリックプレビューで全リポジトリに順次展開中

Stacked Pull Requests（積み上げ型PR）とは

大規模変更 を小さな、明確な Pull Request（PR） に分割する手法
各PRは 順序付けられたレイヤー として構成
個別レビュー やチェックが可能で、全体を一括マージもワンクリックで実現
従来の「巨大な単一PR」や「複数ブランチの手動リベース」の課題を解消

チームでの活用メリット

短く狭い範囲 のPRを並行してレビュー可能
各レイヤーごとに 品質管理 や既存のブランチ保護ルールが適用
一括マージ ・ 部分的なマージ の柔軟な運用
GitHubの 既存レビューやチェック機能 がそのまま利用可能

利用者の声

Next.jsリード Tim Neutkens （Vercel）
- 「小さな変更単位で大きな機能を提供でき、レビューが容易」
jQuery創設者 John Resig
- 「5つの積み上げPRを一度にマージキューへ投入でき、作業効率が大幅向上」
TED CTO Andy Merryman
- 「AI活用でPRが巨大化する課題を、積み上げPRで解決。レビューの精度・速度向上」
WHOOPエンジニア Mayank Saini
- 「大規模変更が小さなPR群になり、全体を一括マージ可能に。GitHub本来の一部に感じる」

CLI拡張機能の導入・利用方法

gh-stack CLI拡張をインストール
- コマンド：gh extension install github/gh-stack
ターミナルや github.com からスタック作成・管理
GitHub CLI、Web、モバイルアプリ、Coding Agent（例：GitHub Copilot）でも操作可能

スタックの作成とレビュー方法

変更ごとに 新規ブランチ・PR を作成し、下層レイヤーをターゲット
各PR画面上部の スタックマップ で全体構成を把握
各レイヤーごとに独立レビュー 可能、チームで並行作業も容易

マージ運用

最新の準備完了PRをマージすると、 未マージの下位レイヤー全てを一括着地
一部のみマージも可能、上位PRは自動でリベース・再ターゲット
既存の ブランチ保護・チェック要件 がそのまま適用

ロールアウト状況・今後

パブリックプレビュー として全リポジトリに順次展開
Merge queue 対応も数週間かけて段階的に提供
詳細は Stacked Pull Requestsドキュメント や GitHub Discussion で確認・フィードバック受付

Hackerたちの意見

これを試すのがめっちゃ楽しみ！Graphiteを使った後、スタックなしのGitHubに戻るのがすごく大変だったから。これでスタックPRのワークフローがもっと一般的になって、巨大なPRの代わりに簡単な選択肢が増えるといいな。

└

git-spiceをおすすめするよ。使いやすくてパワフルだし、もちろんオープンソースだしね。グラファイトも試してみたけど、なんか複雑にしすぎてるなって感じた。

それでメニューのトグルがパンケーキの絵文字（U+1F95E）なの？ちょっとした遊び心はいいけど、その変更で何を見てるのかすごく疑わしくなった。

└

一瞬、redditスタイルのアカウント誕生日バッジかと思った。

└

うん：https://github.com/orgs/community/discussions/203497

└

社内ではパンケーキの絵文字を使ってたから、ちょっとしたイースターエッグだと思ったんだ。数時間だけ表示されて、その後は通常のアイコンに戻るよ :)

これに関連して、呪術のいいところは、ブランチを更新すると、そのブランチから始まった他のブランチもリベースされることだよね。レビューしやすくするために作業を分けたいときは、よくjjに切り替えるけど、gitで作成したクローンと一緒に使うとすごくうまくいくよ。

ちょっとプレビューを使ってみたけど、まだ修正されてない問題がたくさんあるのにプレビューを拡張してるのには驚いた。例えば、スタック全体をマージするのが多くの場合完全に壊れてるんだよね：https://github.com/github/gh-stack/discussions/212 一つずつマージはできるけど、スカッシュ＆マージを使ってると、レビューが必要なスタック内の各PRに対して再承認が必要になる。これだと、スタックPRの最大の利点を失っちゃう。コマンドラインツール（gh stack）は少し手動作業を減らしてくれるけど、git rebaseの仕組みをしっかり理解しておく必要がある。ツールは複数のブランチでの自動化を助けるだけだから。例えば、UIが提案する「gh stack rebase」コマンドを実行しても、ローカルブランチがリモートと同期してないと機能しないし、そのことをツールが教えてくれるわけじゃない。スタックUIは結構いいと思う。スタンドアロンのPRに比べてかなりシンプルだけど、関係性を示すには十分だよ。（私のコメントは、あなたがすでにPRをスタックする良い理由がある前提で書いてるからね。このツールはワークフローを楽にするだけで、新しい機能を提供するわけじゃない。）

└

スクワッシュマージの問題に対するバグ修正を進めてるよ。内部システムのCPRMC（Create Pull Request Merge Commit）を使って、PRが「マージする準備ができているか」を評価してるんだ。これには、マージ可能かどうか（マージコンフリクトのチェック）から、ルールの評価（承認がマージによって作成される可能性のあるコミットと一致しているかの確認）まで含まれてる。特に複数のPRをスクワッシュマージする時は、いくつかのスクワッシュされたコミットを計算して、それをルールやレビューに関連付ける必要があるから難しいんだ。最初のPRは比較的簡単だけど、2つ目以降は先祖コミットがスクワッシュされてそのままのブランチには存在しないから、もっと複雑になる。マルチペアレントの状況になると、さらにややこしくなるのは言わずもがな（笑）。これは修正が必要で、チームの最優先事項なんだ。数字を見ると、スタックマージの99%が成功してるけど、もっと高める必要がある。プレビューの初期ユーザーになってくれて、これらの問題を解決するまで待ってくれてありがとう！

└

ドラフトPRを通常のPRの上にスタックしたらどうなるの？

└

Gitが複雑だと思ってたら、あの優しい同僚から5つも重なったPRが来たら待っててね！冗談はさておき、これは本当に逆機能だよ。これで同僚たちはPRをもっと長い間無視できるようになっちゃった。

こういうスタックPRの利点は、よく整理されたコミットのセットと、コミットごとのレビューに比べて何なの？大きな問題は、大きなAI PRは別のレビュー方法が必要だってことだと思う。例えば、diffの表示順がコミットを読みやすくするのに大きな影響を与えることがある（例えば、関数定義の変更が最初、その後にすべての呼び出し元、最後にテスト）。あるいは、diffとコメントが絡み合うシステムに移行するべきかも。ちょっと「リテラルプログラミング」のように、コードと文章が絡み合う感じで。リテラルdiff / リテラルプルリクエスト…そんなのはまだ見つけてないな。

Hacker Newsで議論の続きを見る

ハクソク