GitHub の stacked PR が GA、承認保持と置換コミットの署名条件

GitHub の stacked pull requests が、2026年10月6日付の changelog で一般提供（GA）になった。github.com の全プランで使え、GitHub Enterprise Server には今後のリリースで入る。GA で加わった改善の多くは、既存のブランチルールとの噛み合わせに関するものだ。古い承認を却下する設定（dismiss stale approvals）があるリポジトリでも、コードが変わっていないスタックを Rebase stack で更新した場合は承認が残る。署名必須のルールがあっても、Rebase stack が作る置き換えコミットには GitHub が署名する。

マージの形も変わった。スタックは merge queue に 1つの merge group として入り、そのまま着地する。merge commit 方式では、マージしたグループ全体で1つだったマージコミットが、PR ごとに1つ作られるようになった。運用前に見直すべきなのは、承認・署名・bypass・マージ方式の4つの設定だ。

スタックの基本的な動き

スタックは順序付きの PR の並びで、各 PR は1つ下の層を base にする。プレビュー時の changelog によると、レビュアーは各層の差分だけを見ればよく、PR 上部のスタックマップで全体の中の位置を確認できる。いちばん上の準備ができた PR をマージすると、その下の未マージの層もまとめて1回の操作で着地する。下の層だけをマージした場合は、上の PR は開いたまま自動で rebase と retarget が行われる。どちらの場合も、main に何が入るかは既存のブランチ保護と必須チェックが決める。

CLI からは拡張機能で扱う。

gh extension install github/gh-stack

GA では、この gh stack 拡張が Git worktree に対応し、初期化・checkout・移動も速くなったとされている。

既存ルールとの関係

既存の設定・機能	stack での扱い（GA 時点）	条件
dismiss stale approvals	Rebase stack で承認が残る	base ブランチが進んだだけで、スタック自体のコードが変わっていない
署名必須ルール	Rebase stack は署名付きの置き換えコミットを作り、元の author を保つ	部分マージ後の自動 rebase は、署名必須ルールがあるか、元のコミットのどれかが署名済みのとき署名する
ルールの bypass 権限	スタック内のいちばん下の未マージ PR をマージできる	bypass 権限を持つユーザー
merge queue	スタック全体が1つの merge group として入り、着地する	merge queue を使うリポジトリ
merge commit 方式	PR ごとにマージコミットを1つ作る	マージ方式が merge commit
base ブランチの削除	スタックを自動で retarget する（以前は一番下の PR を閉じていた）	スタックの base ブランチが削除されたとき

出典：GitHub Changelog「Stacked pull requests generally available」（2026年10月6日）

承認の保持は範囲が狭い点に注意したい。告知が保証するのは、base が進んだあとに更新する、コードが変わっていないスタックの承認保持だ。コードを書き換えた場合まで保持されるとは言えない。承認が必要かどうかは、変更後の各 PR の状態を確認する。

署名の扱いは2つの経路で条件が違う。利用者が自分で実行する Rebase stack は、署名付きの置き換えコミットを作ると書かれている。下の層をマージしたあとに GitHub が自動で行う rebase では、署名必須ルールがあるか、元のコミットに署名済みのものが1つでもあるときに署名する。元の author を保つことと、元の署名をそのまま保持することは別だ。GitHub が新しいコミットに署名する処理として読む必要がある。

公式ドキュメントにも記述の差がある。「Merging stacked pull requests」は Rebase stack が署名済みコミットを生成すると説明する一方、「Managing stacked pull requests」にはサーバー側の rebase は未署名という記述が残る。ここでは新しい GA 告知の説明を扱うが、署名必須の運用へ組み込む際は置換コミットの署名と PR のチェック結果を実際に確かめたい。

merge queue と履歴の形

merge queue を使っているチームにとっては、スタックが1つの merge group にまとまる点が大きい。プレビュー時は merge queue 対応そのものが数週間かけて段階的に展開されていた。GA ではスタック全体が1グループで入って着地すると明記された。

merge commit 方式を選んでいるリポジトリは、マージ後の main の履歴が変わる。複数の PR をまとめてマージしても、merge commit は PR ごとに作られる。マージコミット単位で何かを数えたり、メッセージからリリースノートを組み立てたりしているなら、その前提を確かめておくとよい。squash や rebase 方式での変化は、この changelog には書かれていない。

タイムラインと webhook

PR がスタックに追加・削除されたイベントがタイムラインに出るようになった。pull_request webhook には、PR がスタックに加わったときの action として stacked が入る。action の値で処理を分けている bot や連携があれば、新しい値が届くことになる。changelog が挙げているのは加入時の action だけで、スタックから外れたときに何が送られるかは書かれていない。

ほかに、PR ページの固定ヘッダーにスタック情報が常に表示され、PR 一覧からもスタックの詳細を見られるようになった。一覧画面の刷新は PR 一覧の検索と一括操作の記事 で扱っている。スタック内の移動には Shift + J と Shift + K が使える。auto-merge は2026年10月6日の告知時点では数週間かけて展開予定とされ、選んだ PR のグループが全部マージ可能になった時点でまとめてマージする機能として説明されている。

使い始める前に見直す設定

• dismiss stale approvals: Rebase stack で残るのはコード不変のスタックの承認だけ。レビュアーとの認識を揃えておく。
• 署名必須ルール: 自動 rebase で署名される条件は2つ。ルールで要求していない場合は、元のコミットの署名の有無で結果が変わる。
• bypass 権限: 権限を持つ人がスタックのいちばん下の未マージ PR をマージできる。誰に bypass を与えているかを確認する。
• マージ方式: merge commit 方式なら、マージコミットが PR ごとに作られる前提で履歴を扱う。
• GitHub Enterprise Server: 2026年10月6日の告知では今後のリリースに含める予定。対応するバージョンは示されていない。