GitHubのStacked PRが正式提供：小さくレビューし、CIの重複を抑える設計

GitHub Pull Request CI/CD コードレビュー
<style> .sp-hero{padding:clamp(25px,5vw,46px);border-radius:22px;color:#fff;background:linear-gradient(125deg,#182638,#264f73 55%,#477aa3)}.sp-hero h2{color:#fff;margin:.35em 0}.sp-kicker{font-size:.79rem;font-weight:800;letter-spacing:.13em;color:#b7dbf2}.sp-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:20px 0}.sp-card{padding:18px;border:1px solid #c9dce9;border-radius:13px;background:#f0f6fa}.sp-card strong{display:block;color:#245479;font-size:1.2rem}.sp-stack{max-width:620px;margin:20px auto;padding:16px;border-radius:15px;background:#edf5fb}.sp-layer{padding:12px 16px;margin:7px;border-radius:9px;background:#fff;border-left:5px solid #4a80b0}.sp-layer b{color:#20517a}.sp-table{overflow-x:auto;margin:20px 0}.sp-table table{width:100%;min-width:550px;border-collapse:collapse}.sp-table th,.sp-table td{padding:11px;border:1px solid #c9dce9;text-align:left;vertical-align:top}.sp-table th{background:#e8f1f8}.sp-note{padding:17px 19px;margin:20px 0;border-left:5px solid #cb9954;border-radius:9px;background:#fff8ea}@media(max-width:760px){.sp-grid{grid-template-columns:1fr}} </style>

DEVELOPMENT / REVIEW WORKFLOW

大きな変更を、依存関係ごとに分ける

GitHubのStacked PRが正式提供。レビューを小さくしても、CIとマージ順序の設計は必要だ。

3行で要約

  • GitHubは2026年10月6日、複数の依存PRを一つの連鎖として扱うStacked pull requestsの一般提供を発表した。[1]
  • 各PRは直下のブランチをbaseに持ち、差分を層ごとにレビューできる。GitHubはbase側の保護ルールとCIを各層へ適用し、下層から順にマージする。[2]
  • CIはスタック内の各PRで走るため、分割数に比例して実行量が増え得る。必須チェックを維持しつつ、重い任意ジョブの実行位置を設計したい。[3]

背景と、今回新しいこと

データベースのスキーマ変更、API、画面を一つの巨大なPRにすると、レビュー対象が広くなる。一方で依存する変更を別々のPRにすると、baseブランチの付け替えやリベースが面倒になる。Stacked PRは、前のPRを次のPRのbaseにする依存チェーンをGitHub上で扱う仕組みだ。[2]

GitHubの正式提供日は10月6日。本記事の公開は日本時間10月10日で、ニュースの発生日とは別である。直近の当サイトではGitLabのDependency FirewallやGitHubの非同期マージAPIを扱った。今回はPRを分割してレビュー・CIを運用する方法が主題で、機能や対象業務は異なる。

仕組み：下のPRに依存する上のPR

各PRには、その層固有の差分だけが表示される。レビューと承認は層ごとに進められるが、依存関係は残るためマージは下から上へ。下層をマージすると、残る上層のブランチは自動でリベース・base変更される。GitHubはスタックの情報をPR画面で表示し、Shift+J/Shift+Kで層を移動できるとしている。[1][2]

小さな差分層ごとに独立してレビュー
保護ルール下層のbaseにある要件を各層へ適用
自動リベース下層マージ後に残りの層を更新

技術的なポイント：CIは各層で実行される

GitHubの説明では、スタック内の各PRはスタック全体のbase、たとえばmainを対象とするかのようにGitHub Actionsのワークフローで評価される。これによりmain向けの必須チェックは上層でも走る。一方、PRを3層にすれば同じ重いジョブが3回走り得る。レビューしやすさとCI費用は別の指標だ。[2][3]

スタック運用で分けるCIの判断
ジョブ実行方針の例注意点
型検査・単体テストなど必須チェック各PRで維持層ごとの品質条件を落とさない
高コストの統合・性能試験最上層や下から最初の未マージ層に限定を検討対象外の層をマージしてよいか別途判断
デプロイ変更の影響範囲と承認手順に応じて限定上層は下層を含む状態であることを確認

ワークフローではgithub.event.pull_request.stackにスタック情報が入り、position（1から始まる位置）とsize（PR数）を参照できる。スタック外PRではこの値がないため、条件式では存在確認を先に入れる。公式文書には最上層だけを選ぶ条件例がある。必須チェックの省略がブランチ保護に影響する場合は、先にルールを確認する。[3]

導入手順：2層から試す

  1. GitHub CLI 2.90.0以上、Git 2.20以上を確認し、プッシュ可能なテスト用リポジトリを用意する。gh auth loginで認証し、gh extension install github/gh-stackで拡張を導入する。[4]
  2. gh stack initで最初のブランチを作り、小さな土台変更をコミットする。次にgh stack add BRANCH-NAMEで上層のブランチを作り、依存する変更をコミットする。[4]
  3. gh stack pushでブランチを送信し、gh stack submitでPRを作成・連結する。gh stack viewで順序と状態を確認する。[4]
  4. 最初は2層で、差分、必須チェック、承認の維持、下層マージ後のリベースを確認する。GitHubは正式提供時、変更のないコードへの承認維持や署名付きリベースコミットなどの改善を挙げたが、既存のルールセットとの組み合わせは実際のリポジトリで試したい。[1]

開発チームへの影響、リスクと限界

レビュー単位が小さくなると、土台変更と利用側の変更を担当者ごとに見やすくなる。ただし上層PRだけを見て土台の影響を見落とす危険もある。GitHubが示すプレビュー利用リポジトリのマージ量・時間の改善は同社観測値であり、スタック機能だけによる因果効果や全チームでの再現を保証しない。[1]

また同一リポジトリ内のブランチが前提で、forkをまたぐスタックやGitHub Desktopは対象外と公式文書にある。既存のCIやボットがPRのbaseをmainと決め打ちしている場合、スタック情報への対応を確認したい。[2][3]

今後はEnterprise Serverへの提供時期、自動マージのロールアウト完了、CI実行量とレビュー所要時間の実測を追う。最初から大きなスタックを作るより、2層でルールとCIの動きを検証する方が安全だ。

最終確認日：2026年10月10日（日本時間）

参照元

  1. GitHub Changelog：Stacked pull requests generally available — 正式提供日と変更点。
  2. GitHub Docs：About stacked pull requests — 依存関係、レビュー、ルール、制限。
  3. GitHub Docs：Optimizing CI for stacked pull requests — CIの実行条件とメタデータ。
  4. GitHub Docs：Quickstart for stacked pull requests — CLIによる初期設定と作成手順。

Previous Post Next Post