GitHub Stacked PRs

 (github.github.com/gh-stack)
9 ポイント 投稿者 GN⁺ 16 일 전 | 1件のコメント | WhatsAppで共有
  • 大規模なコード変更を小さくレビューしやすいPR単位に分割し、順番に管理できるようにするGitHubの新機能
  • 各PRは独立してレビューされ、スタック全体はワンクリックでマージ可能
  • GitHub UIとgh stack CLIを通じてスタックの作成、移動、リベース、マージをサポートし、スタックマップで階層構造を可視化
  • AIコーディングエージェント統合により、大規模なdiffを自動でスタック単位に分割したり、スタックベースの開発を行ったりできる
  • 大規模PRの複雑さと競合リスクを減らし、レビュー効率とチーム開発速度を高めることが目的

主な機能

  • スタック型PR管理

    • 複数のPRを順序付きのスタック(stack) 形式で構成し、各PRは直下のPRのブランチを基盤とする
    • 最終的にメインブランチへ到達するチェーン構造を形成
    • GitHubはスタック全体を認識してUIにスタックマップ(stack map) を表示し、レビュアーが各階層を簡単に移動可能
    • ブランチ保護ルールは最終的な対象ブランチに適用され、CIテストはスタック内のすべてのPRに対して実行される

  • 簡素化されたスタック管理

    • GitHub UIでスタック内のPR間を移動し、各階層の状態を確認し、スタック全体に対する連鎖リベース(cascading rebase) を実行可能
    • ワンクリックでスタック全体をマージすることも、一部だけをマージすることも可能
    • マージ後に残ったPRは自動でリベースされ、最下層の未マージPRがベースブランチを対象に調整される

  • 強力なCLIサポート

    • gh stack CLIにより、スタック作成、リベース、ブランチのプッシュ、PR作成、階層間の移動をターミナルで実行可能
    • CLIコマンド例
      • gh extension install github/gh-stack : 拡張機能をインストール
      • gh stack alias : 短縮コマンドを設定
      • gs init <branch> : 最初のブランチを作成
      • gs add <branch> : 新しい階層を追加
      • gs push : すべてのブランチをプッシュ
      • gs submit : スタック全体のPRを作成

  • AI Agent統合

    • npx skills add github/gh-stack コマンドでAIコーディングエージェントがスタック作業を実行できるよう学習させられる
    • 大規模なdiffを自動でスタック単位に分割したり、最初からスタックベースの開発を進めたりできる

スタック型PRが必要な理由

  • 大規模PRはレビュー難易度の上昇、マージ遅延、競合リスクを招く
    • レビュアーが文脈を見失い、フィードバックの質が低下し、チーム全体の速度が落ちる
  • Stacked PRsはこれを解決するため、小さく焦点の定まったPRチェーンに分割する
    • 各PRは独立してレビュー可能で、変更全体は順番に積み上がる

はじめ方

関連記事

1件のコメント

 
GN⁺ 16 일 전
Hacker Newsの意見

  • 私に必要なのは「stacked PR」ではなく、単一コミット管理用UIだ

    • 一部のコミットだけを独立してマージしたり、特定のコミットをレビュー完了としてマークしたい
    • コミット単位で interactive rebase/squash/edit をしたいが、GitHub UIでは不可能だ
    • コミットメッセージや特定のコミットにコメントを付ける機能、そして diff of diff で強制プッシュ間の変化を可視化する機能が必要だ
      Gitはすでにコミットという概念を持っているのに、なぜその上にさらに「stacked PR」という抽象化を載せるのかわからない
    • Phabricatorが作った stacked diffワークフロー をGitHubに持ち込んだ概念だ
      まだマージされていない作業の上で新しい作業を進めやすくし、レビュアーが大きな変更を 小さな単位で独立してレビュー できるようにする
      大規模なmonorepoや企業環境では特に有用だった
    • ただ、私は gitの履歴を継続的に書き換える のは危険だと感じる
      squash、rebase、force pushを繰り返すのは自分の足を撃つようなものだ
      git merge --no-ff、git log --first-parent、git bisect --first-parent でも十分同じ効果を得られる
    • Metaで使っていた SuperSmartLog(SSL) が最も優れた実装だった
      interactive smartlogドキュメント で公開されていて、VSCode拡張もある
      意外なほど広く使われなかったのが残念だ
    • 私が好むワークフローは、PR/MRを 「原子的な変更」 として見ることだ
      コミットはそのPRを完成させるための進化の過程として使う
      1. PRが大きすぎるならコミットに分ける
      2. PRの発展過程をコミットに記録する（「fooをbarに変えた」のような理由も含めて）
    • あなたが言っているのは実質的に Gerrit だ

  • PhabricatorとMercurialを使ってからGitHubに戻ると、石器時代 に戻った気分になる
    stacked diffの流れを再実装してくれるjujutsuや今回の機能は歓迎だ
    monorepoだけでなく長期の機能開発でも、レビューを小さく速くできるようにしてくれる

    • GitがDVCS戦争に勝って本当によかった
      Mercurialはいつも「gitより速い」と言っていたが、実際には遅かったり壊れたりしていた
      Gitは 醜いが速くて信頼できる
    • 私は今でもGitHubレビューが嫌いなので Gerrit を使っている
      大きな変更（例: vendor依存関係の更新）をレビューするとき、GitHubのファイルレビュー体験は微妙だ
    • PhabricatorのレビューUI がとても恋しい

  • ついに来た！
    GitHubの「PR=ブランチ」モデルは理解できなかった
    Phabricator/Gerrit式のstacked commit の方が自分の考え方に合っている
    これでCLIをインストールしないといけないな

    • GH CLI依存なのは残念だが、GAの時点ではUIサポートが入ってほしい
    • 私の頭の中のモデルでは、ブランチとstacked PRの違いがよくわからない
      ブランチは単にコミットに旗を立てるだけで、複数の地点を残すことに意味があるのは、前の部分を独立してマージできるときだけだ

  • 現在 Squash & MergeのUX問題 を解決したのか気になる
    私は手動で main <- PR A <- PR B <- PR C のように積んでいるが、
    PR Aが先にマージされるとPR Bは衝突地獄になる
    GitHub UIが自動でターゲットブランチをmainに変えて 妙な衝突 が発生する
    とにかく「ちゃんと動く」ツールが必要だ

    • 衝突はPR Aが squashマージ されたせいである可能性が高い
      gh stack sync が rebase --onto で解決してくれることを期待する
    • 実際にはCLIとサーバーで git rebase --onto により処理している
      例: PR1(main<-A,B)、PR2(main<-A,B,C,D)、PR3(main<-A,B,C,D,E,F)
      PR1、2がsquashマージされると、mainは S1(A+B)、S2(C+D) になる
      その後 git rebase --onto S2 D branch3 で衝突なく整理できる
    • 私のワークフローではAがマージされたらBもすでにマージ済みであるべきだ
      git rebase --update-refs --onto origin/main A C で解決できる
      GH CLIがこの過程を自動化してくれる
    • この問題は gitの論理的限界 であってバグではない
    • 私もこれが 苛立たしく直感的でない ことには同意する
      だが解決策は結局、手動rebaseでコミットを整理することしかない

  • 一人で開発するときはstacked PRはほとんど必要ないが、小さな単位に分ける習慣 は依然として重要だ
    AIツール（例: Claude Code）が一度に大きなdiffを作るので、
    エージェントが自分で作業を論理的な単位に分ける機能が出てきたら面白いと思う

    • そもそもPRは複数コミットで構成できるので、エージェントがそれをうまく辿れないならstacked PRでも同じ はずだ
    • 私はClaudeとjjを一緒に使って、作業スタックをtrunk上で レビューしやすい形に再構成 させている
    • 小さなブランチを相互依存にすると、前のブランチが更新されたときに同期地獄 が起きる
    • 関連するエージェント統合ガイドはWebページで確認できる

  • git-spice も試してみる価値がある
    GitLabなどと互換性があり、私は既存のgitコマンドの代わりに全部git-spiceを使っている

  • GitHubがついにUIに stack機能 を入れたのは素晴らしい
    GitLabの glab stack に似ている
    ただしマージの流れは少しぎこちなさそうだ — スタックの下側をマージすると残りがrebaseされて CIが再実行される
    3つのパッチのうち下2つだけをマージしたい場合、それぞれのテスト待ちが必要になる

    • 現在の設計では、下2つのPRのCIが通れば一度にマージ可能 だ
      その後、上側のスタックがrebaseされてCIが再実行される可能性がある
      ドキュメントにもこの点を明確に追記する予定だ

  • 私は stacked PRの必要性 がよくわからない
    gitではもともとパッチセットを個別にレビューして適用できる
    PRモデルの方がむしろこれを ひとつの塊にまとめてしまう
    stacked PRはその問題を回避するための別の抽象化に見える

    • 私がいたチームではPR自体を「適用可能な最小単位」と見ている
      内部コミットは開発履歴にすぎず、マージ時には squash してひとつにまとめる
      こうすれば開発中は自由にコミットを積めて、マージ時にはきれいな変更だけが残る
    • Phabricatorではコミットとdiffが1:1だったので、ずっと自然だった
      GitHubの実装は少し 後付けの機能 のように感じる
    • PRは本来 原子的な変更単位 で、stacked PRはその上に新しいPRをベースにして作業できるようにするものだ
      つまり、レビュー可能な単位で 作業を段階的に積み上げる構造 だ

  • Graphite というスタートアップがすでにstacked PRに注力している
    私はGraphiteを使ってきたので、GitHubが似たものを実装したのはうれしい

    • 会社でもGraphiteを使っていて満足している

  • 私はstacked PRは好きだが、今回のGitHub実装は 変なやり方 に感じる
    単に各ブランチが親を指すようにすれば十分だ
    CLIより UIサポート の方が必要だ

    • ただし親ブランチがマージされた後のrebaseは苦痛だ
      CLIがこの過程を自動化してくれるとよさそうだ
    • CLIは必須ではなく、UIでもstacked PRを作成できる
      ブランチチェーンを置く理由は、diffが そのブランチの変更だけを表示するため だ
    • 実際これは もともとgitでも可能 だった
      ただ、UIと可視化が不足していただけだ
    • 次はUI改善が来ることを期待している