依存する変更をまとめたPRでは、確認範囲が広がります
たとえば、開発者が型定義（データの項目や値の形式を定める記述）を使うAPI（ソフトウェア同士の連携窓口）を作り、そのAPIを呼び出す画面を実装する場面を考えます。PR（プルリクエスト）は、コード変更を別のブランチ（変更履歴を分岐させた作業系統）へ取り込む提案で、レビューや議論を行う場です。こうした変更を一つのPRにまとめると、レビュー担当者はデータの形、処理、表示を一度に確認します。Gitの公式説明が扱うブランチは、変更履歴を分岐させた作業の系統です。
開発者が変更を層ごとに分けると、レビュー担当者は各PRの確認範囲を絞れます。GitHubは、小さく焦点を定めたPRでは、差分（変更前後で異なる部分）が流し読みされにくいと説明しています。これはGitHubの説明であり、本稿ではレビュー速度や品質を測定していません。[11]
ただし、画面はAPIに、APIは型定義に依存します。型定義のPRが未マージ（変更が対象ブランチに取り込まれていない状態）の間は、後続作業の担当者が土台の取り込みを待つ場合があります。依存するPRを連鎖させれば、土台のレビュー中も、その変更の上で次の層を作業できます。[12]
手動の依存PRにも役割があり、連鎖の管理作業が残ります
従来も、先行ブランチを次のPRのbase（PRが取り込みを提案する先）に指定し、依存PRを手作業で連鎖させられました。GitHubによる手動の依存PRの説明この方法なら、層ごとにレビューしながら、先行PRのマージを待たずに作業を進められます。GitHubは、手動の依存PRでは下層の変更や基準ブランチの更新に伴う同期が煩雑になり、誤りを招きやすいと説明しています。rebaseは、ブランチの変更履歴を別の基準の上に積み直す操作です。[17]
保護ルールは、ブランチへの取り込み条件を定める設定です。CIは、変更に応じてビルドやテストを自動実行する仕組みです。手動の依存PRでは、ブランチ保護ルールの適用やCIチェックの実行が最下段のPRに限られる場合があります。その場合、上層の状態を確認しにくくなります。GitHubによる手動連鎖の課題の説明本稿の運用案として、チームが各PRの検査設定と状態を管理する方法を提案します。
| 方法 | 差分の見方 | 更新時に残る作業 | 選び方の目安 |
|---|---|---|---|
| 単一PR | 全変更を一つの差分で確認 | 一つのブランチを更新 | まとまった変更を一度にレビューするとき |
| 独立した小分けPR | 各PRの変更を個別に確認 | 各ブランチを更新 | 互いに依存しない変更 |
| 手動の依存PR | base指定で層ごとに比較 | 上層の同期と検査設定を管理 | 既存の連鎖運用を続けるとき |
| Stacked PR（依存するPRをつなぐ機能） | 各層と直下ブランチ間の差分を確認 | 同期機能を使い、競合と検査設計に対応 | 依存する変更を分けて進めるとき |
後輩分割の価値があるかは、PRの数より依存関係で決まりそうですね。
先輩そうだね。独立した変更なら別々に進められるし、依存があれば上段が下段を必要とする。連鎖の管理負担も選択に入るよ。
後輩手動運用が回っているチームにも、移行の判断材料はありますか。
先輩下層修正の同期や、各PRの検査状態を保つ作業がどれだけ発生するかを見ればよいね。
Stacked PRはbaseを連鎖させ、層ごとの差分を扱います
GitHubは2026年10月6日、Stacked pull requestsの一般提供を発表しました。github.comの全プランが対象で、GitHub Enterprise Serverには今後のリリースで含める予定です。[3]
Stacked PRは、同じリポジトリ（コードや変更履歴を管理する保管場所）内の複数PRを依存順につなぐ機能です。trunkは最下段PRの基準となるブランチで、ここではmainを指します。
mainをtrunkにする例では、型PRのbaseをmain、API PRのbaseを型ブランチ、画面PRのbaseをAPIブランチにします。baseは、PRが取り込みを提案する先です。レビュー担当者は各PRの画面で、その層の差分を確認できます。[2, 13, 16]
矢印はbaseの連鎖を示す概念図です。型の修正をAPIや画面の変更と分けてレビューしながら、上段の作業を下段の未マージ変更の上で進められます。[18]
下層を直したら、上層のブランチを更新済みの下層へ載せ直します。この操作をcascade rebaseと呼びます。rebaseは、ブランチの変更履歴を別の基準の上に積み直す操作です。gh stack rebase --upstackは変更箇所より上のブランチを順に更新し、gh stack pushでリモートへ反映します。[7, 17]
一般提供の告知は、base branchが進んでもスタックの差分が変わらない場合、Web上の「Rebase stack」が承認を保持すると説明しています。作り直す置換commit（変更履歴の記録）には署名が付きます。10月7日時点の一部公式文書には、public preview（一般向け試験提供）の表記が残っています。これはGA（一般提供）の告知と異なる状態表記です。利用時は実際の操作画面やリポジトリのルールを確認してください。[4, 10]
レビューとマージは下から連続した範囲で進みます
Stacked PRでは各層を個別にレビューできます。マージは、最下段の未マージPRから始まる連続範囲で進みます。たとえばAPI PRを取り込む場合、下にある型PRも範囲に含まれます。中段のPRだけを単独でマージする操作には対応していません。[1, 6, 21]
対象PRと、その下にあるすべてのPRが、stack base向けのブランチ保護要件を満たす必要があります。要件には必要なレビュー、required checks（必須の自動検査）、CODEOWNERS（コード所有者を指定するファイル）の承認などがあります。公式の参照文書スタックにはlinear history（枝分かれせず直線的につながる履歴）も求められます。レビューと検査は各層で行い、条件を満たした連続範囲をマージします。[6, 14]
merge queueは、PRの取り込み前に検査・処理するキューです。merge groupはそこでまとめて検査するPR群、merge commitは取り込みを記録するコミットです。GA告知は、スタックを一つのmerge groupとして扱い、merge commit方式ではPRごとにコミットを作ると説明しています。[5]
10月7日に保存した資料と、10月10日に確認した現行文書の記述には差があります。現行のマージ文書は、スタックを維持するためgroupの設定上限を最大50%超過できると説明しています。
同文書は、その範囲にも収まらないスタックを次のmerge groupへ「as a single unit」（単一単位として）移すと明記しています。現行文書のmerge queue条件
一方、公式のトラブル対処文書には、大きいスタックが連続する複数のmerge groupに分かれる場合があると記載されています。二つの文書の記述差は残っており、本稿では実際の分割動作を再現確認していません。導入担当者は、利用する構成のqueue設定と処理結果を確認します。
auto-merge（条件を満たした後の自動取り込み）は、10月6日の告知では数週間の段階展開予定でした。[5] 一方、10月10日取得の本文には「Auto-merge is not supported for stacked pull requests.」とあり、未対応と記載されています。現行文書の利用条件 導入担当者は、告知の予定と現行文書の記載を区別し、実際の操作画面とルールを確認します。
後輩各層を別々に読めても、取り込みの判断では下の変更まで見ることになるんですね。
先輩そうだよ。レビュー単位は層ごとに保てるけれど、取り込み可能な範囲は依存関係に沿って決まるんだ。
後輩その条件なら、上段の作業を急ぐほど下段のレビューも重要になりますね。
先輩その通り。各PRの承認とchecksを揃える運用を、スタック全体で考える必要があるね。
CI負荷とチームの条件に合わせて、適用する変更を選びます
Stack内では設定済みworkflow（自動処理の定義）が各PRで実行されるため、段数が増えるとCI使用量も増えます。公式ガイドはstack metadata（段の位置などの付帯情報）を使い、高コストのjob（処理単位）を最下段の未マージPRか最上段に絞る例を示しています。required checks（取り込みに必須の自動検査）など、各PRの保護ルールを満たす条件は引き続き確認します。各層の承認と必要な検査は、リポジトリの取り込み条件に沿って維持します。[8, 14]
公式Quickstartは、GitHubをコマンドで操作するGitHub CLI（gh）2.90.0以降と、Git 2.20以降が必要です。gh extension install github/gh-stackによる拡張導入を前提にしています。Quickstartの手順では、gh stack initでスタックを初期化し、gh stack add BRANCH-NAMEでブランチを追加します。その後、gh stack push、gh stack submitの順で提出します。下層の変更後に行うrebaseは、前節の管理手順です。pushでは--force-with-leaseが使われます。Gitの公式説明では、このオプションはリモートの履歴が想定した状態かを確認してから書き換えます。[7, 9]
rebaseで競合が起きると処理は止まります。競合を解消した後、gh stack rebase --continueで続けるか、gh stack rebase --abortで中止します。複数人が同じstackを別々に更新してブランチが分岐した場合、自動同期できず、同期処理が止まることもあります。共同変更や競合の解消には、チーム内の更新調整が必要です。本稿の運用上の提案として、更新担当や同時更新を調整する方法をチームで決めます。[7, 20]
利用条件は、すべてのブランチが同一リポジトリ内にあることです。異なるfork（分岐したリポジトリ）をまたぐcross-fork stackと、GitHub Desktopはサポートされません。大量のコードや、独立PRに分けにくい大きな機能を扱い、未マージ変更に依存する作業を続けたいチームは候補になります。本稿の選定案では、独立した変更には小分けPR、まとまった変更には単一PRも候補にします。開発チームは依存関係と同期・CIの負担を比べて選びます。[15, 19]
本稿は保存された公式snapshot（特定時点の保存資料）をもとに、2026年10月7日時点の記述を整理しています。マージ条件は10月10日の現行文書も再確認しました。コマンドの実行や利用状況の検証は行っていません。公式資料間で提供状態の表記に差があるため、導入時は実際の操作画面とリポジトリのルールも確認してください。[10]
