GitHub stacked PR GA：小さな差分と単独で配布できる変更は別

大きな変更を三つのPRに分けると画面は読みやすくなります。ただし上のPRが下の変更に依存するなら、単独で配布できるとは限りません。

10月6日の発表

GitHubは2026年10月6日に一般提供を発表しました。小さなPRを別々にレビューして一緒にマージでき、github.comの全プランで利用可能です。

スタックはmerge queueに一つのmerge groupとして入ります。一方merge commit方式ではPRごとにcommitを作ります。テスト対象と履歴の単位を同一視しないでください。

Aが共通関数、BがAPIの呼び出し、CがUIとします。依存PRと比較baseを各説明に記載します。これは運用提案であり製品の自動保証ではありません。

BだけではAの認可漏れを見逃すかもしれません。各差分の確認とA+B+Cの統合検証を分け、最終組み合わせの担当を決めます。

GitHubはbaseが進んだ際、それ以外に変更のないスタックをrebaseしても承認を保持すると説明しています。古い承認を無効化する設定でも適用されます。承認と現在の統合結果は別の根拠です。

前後のSHAとテストしたmerge groupを記録しましょう。再実行の有無とログの対象を確認し、緑のチェックだけでリリース根拠にしないようにします。

関数とAPIを一緒に配布する必要があれば計画に残します。PR別commitがあっても単独rollbackで残る呼び出し側が壊れないとは限りません。

独立した修正を無理にスタック化する必要はありません。一つのテスト遅延が全体を待たせる可能性もあるため、運用負担を評価します。

auto-mergeは今後数週間で展開予定と発表されています。今日すべてのアカウントに同じボタンがあると考えず、実際の画面を確認しましょう。

previewの意見が操作や自動化の改善につながったと説明されています。関心の根拠であって自分のチームの生産性保証ではありません。待ち時間と統合失敗を測りましょう。

関数と呼び出し側など、明確に依存する二つのPRで始めます。base、依存、テスト手順を記載し、統合責任とrollback範囲を合意します。

レビュー短縮と失敗増加を併せて比較します。維持費が大きければ通常のPRに戻せます。差分数よりレビューと配布の混乱が減ったかを判断基準にしましょう。

発表は10月6日、確認日は2026年10月8日です。導入前に規則と利用可能機能を確認してください。