ハクソク

世界を動かす技術を、日本語で。

GitHubのスタックされたプルリクエスト

2026年4月14日原文(github.github.com)

概要

  • 大規模な変更 を小さな レビュー可能なPull Request(PR) に分割するメリット
  • GitHubの ネイティブサポート と gh stack CLI の活用方法
  • Stacked PR の管理・レビュー・マージの流れ
  • CLIコマンド例 と導入手順の簡単なガイド
  • AIエージェント連携 による開発効率化

Stacked Pull Requestの基本とメリット

  • 大規模な変更 は小さく焦点を絞ったPRに分割し、 順序立ててレビュー する運用
  • 各PRは 独立したレイヤー として扱い、 個別にレビュー・承認 可能
  • GitHub UI 上でスタック全体を一目で把握でき、 ワンクリックで全体マージ も対応
  • gh stack CLI によるローカルでのスタック作成・管理・リベース・PR作成の自動化
  • AIエージェント （例：npx skills add github/gh-stack）との連携による自動化支援

Stacked PRの運用フロー

  • スタックは 同一リポジトリ内の一連のPR で構成し、各PRは 下位のPRのブランチ をターゲットにする
  • 最終的に mainブランチ 等のターゲットブランチに連なる 順序付けられたチェーン を形成
  • GitHubは 全レイヤーのスタックマップ を表示し、 ブランチ保護ルールやCI も最終ターゲットブランチ基準で適用
  • gh stack CLI でブランチ生成・リベース・GitHubへのプッシュ・PR作成を一括管理
  • マージ時は スタック全体または一部を一括マージ し、残りのPRは 自動リベース される

gh stack CLIの導入と基本コマンド

  • CLI拡張のインストール
    • gh extension install github/gh-stack
  • コマンド短縮エイリアス （任意）
    • gh stack alias
  • スタックの初期化
    • gs init auth-layer
  • 新しいレイヤーの追加
    • gs add api-routes
    • gs add frontend
  • 全ブランチのプッシュ
    • gs push
  • スタックPRの作成
    • gs submit

Stacked PRの利点と現場課題の解決

  • 大規模PRの問題点
    • レビュー困難、マージ遅延、コンフリクト頻発、レビューアの文脈喪失、フィードバック品質低下、チーム全体の開発速度低下
  • Stacked PR導入による解決策
    • 変更点ごとに 小さく焦点を絞ったPR を積み重ね、 独立レビュー と 迅速なマージ を実現
    • 開発初期からスタック運用 することで、 大規模diffの分割 や 段階的な開発 が容易

スタック管理の実践ポイント

  • GitHub UI でレイヤー間ナビゲーションとスタックマップ確認
  • CIや保護ルール が最終ターゲットブランチ基準で自動適用
  • マージキュー や 直接マージ の選択肢
  • マージ後の自動リベース による後続PRの整合性維持

導入ガイドと次のステップ

  • Quick Startガイド や 詳細なドキュメント で運用開始をサポート

  • AIエージェント連携 でさらなる自動化・効率化推進

    • 開発現場の コードレビュープロセス最適化
    • チーム開発の生産性向上

Hackerたちの意見

やっとだ！GitHubがデフォルトで使ってるPR=ブランチモデルがずっと理解できなかったんだ。スタックコミット（Phabricator/Gerritみたいなやつ）の方が、変更について考えるときに頭に合ってる。こういうオプションが出てきて嬉しいな。これからCLIもインストールしなきゃね。

└

最初に気になるのは、GH CLIに頼らなきゃいけないところかな。俺も使ってないし。でも、GAになる頃にはUIサポートが追加されてるかもね。

PhabricatorとMercurialを使ってた者として、GitHubとGitを再び使うのは石器時代に戻る感じがする。これと呪術があれば、Phabricatorのスタック差分フローを再現できるといいな。モノレポだけじゃなくて、長期的な機能プロジェクトのレビューや作業がずっと楽になるんだよね。小さなPRや差分を促進するから、ビルドの合間にサクッとレビューできるし（長いプルリクエストは時間がかかるから）。

└

GitHubのレビューが耐えられないから、Gerritを使い続けてるよ。理論上は、変更を小さくするべきなんだけど、大きな作業（ベンダー依存関係の更新とか）をやってると、GitHubでファイルをレビューするのは…あんまり良くないね。

└

Gitがdvcs戦争に勝ったことが本当に嬉しい。Mercurialが「Gitより速い」ってずっと宣伝してた時代があったけど、試してみるたびにいつも遅いか壊れてた（時々）。Gitは見た目はイマイチだけど、速くて信頼できるし、これでやっていける。

└

PhabricatorのレビューUIが恋しいなぁ。

ソロ開発者としてはスタックPRはあまり必要ないけど、PRを小さくてレビューしやすく保つっていう根本的な問題は、たとえ自分がレビューしてもリアルだよね。作業を始める前に小さなブランチに分けるように自分を強制するのが、実際のディシプリンだと思う。そうしないときの苦痛を和らげるのがツールなんだよね。AI支援のワークフローに何か変化があるか気になるな。今はClaude Codeに機能ブランチで作業させてるけど、自然に一つの大きな差分ができちゃう。エージェントが自分の作業を論理的な塊に分けられるようになれば、スタックPRは面白くなるかも。

└

ウェブページにアクセスすると、エージェントの統合手順が表示されるよ。

└

そのためのツールはすでに存在してるよ。PRは複数のGitコミットで構成できて、UIで別々に見ることもできる。エージェントがそれをうまくナビゲートできるかは分からないけど、できないならスタックPRでもあまり変わらないと思う。スタックPRはレビュー過程に新しい利点を生むけど、君が求めてるものとは違う気がするな。

└

もしかしたら知らないGitのトリックがあるかもしれないけど、互いに小さなブランチを作るのが辛いと感じてる。以前のブランチを更新すると、依存してるブランチが同期しなくなって困るんだ。以前のブランチがマスターにリベースされると、進行中のブランチを更新するのが面倒になるよ。

└

Claudeとjjを使って、やった作業のスタックを元に、レビューしやすい新しいスタックを作るっていうのがうまくいってるんだ。

何か見落としてるかもしれないけど、俺が必要なのは「スタックされたPR」じゃなくて、単一のコミットを管理するためのちゃんとしたUIとインターフェースなんだよね。具体的には、 - 一部の作業が準備できたら、独立してコミットをマージしたい。 - いくつかのコミットをレビュー済みとしてマークしたい。 - インタラクティブリベースやスカッシュ、個別のコミットを編集するためのUIがほしい。 （コマンドラインではうまくできるけど、GitHubのインターフェースだと難しいし、チームの全員がそれに慣れてるわけじゃない） - 特定のコミットやコミットメッセージにコメントを付ける機能。 - 各強制プッシュ/リビジョンでの変更を視覚化するためのより良い方法（diff of diff）。 Git自体はコミットの概念を持ってるのに、なんでこの「スタックされたPR」って抽象化を上に乗せるの？それとも、俺が見えてない違いがあるの？

Hacker Newsで議論の続きを見る