GitHubがスタックドPRを取り込む: Meta・Googleのワークフローはついに大衆化するのか

スタックドdiffのワークフローはついにGitHubで主流になるのか、それともgitのブランチモデルが本来表現できないものをツール層で無理やり支える弥縫策の拡散にすぎないのか。

はじめに — 7月30日、GitHubが遅れて到着した場所

2026年7月30日、GitHubはスタックド・プルリクエスト (stacked pull requests) をパブリックプレビューで公開した。一つの大きな変更を順序のある複数層の小さなPRに割り、各PRがすぐ下のPRをベースブランチとして積み上がるようにする機能である。レビュアーは巨大なdiff一つではなく、focusされた小さな層を一つずつ検討する。GitHub CLIの拡張で gh extension install github/gh-stack を入れれば使え、github.comのウェブ、GitHub CLI、モバイルアプリ、そしてコーディングエージェントでも動く。今後数日かけて全リポジトリへ順次展開され、マージキュー (merge queue) 対応は数週間かけて後を追うとGitHubは述べている。

この発表がHacker Newsのトップページに載り、投稿は760ポイントを集めた。興味深いのは反応の温度である。新機能への純粋な歓迎よりも、「今さら?」に近い声が先立った。理由は明白だ。スタックドdiffは新しいアイデアなど微塵もないからである。MetaはPhabricatorとSaplingで、GoogleはCritiqueとGerritで十数年この方式を社内標準として回してきたし、GraphiteのようなスタートアップはGitHubの上でこのワークフロー一本で事業を立てた。だからこの発表の本質は「発明」ではなく「受容」である。本稿はまずスタックドPRが実際に何をするのかを確定し、なぜこのワークフローが存在し、なぜよりによってgitでそれが難しかったのかを解剖したうえで、チームとエンジニアにとってスタックがいつ利得でいつ過剰なのか、そしてこの受容がツールの生態系に何を残すのかを整理する。

現状 — スタックマップとカスケードマージ: スタックドPRが実際にすること

まず機能の実体から確定する。スタックドPRの核となるUIはスタックマップ (stack map) である。各PR画面に、この変更がスタック全体のどの層に置かれるのかを図で示す。下から上へA → B → Cの順に積まれた三つのPRがあれば、Bのレビュアーは、BがAの上に載りCがBに依存するという関係を一目で見る。この地図があるため、レビュアーは各層を独立に検討でき、下層のレビューが終わるのを待たずに並列で承認を進められる。

二つ目の仕掛けはマージの挙動である。GitHubの表現をそのまま移せば、準備の整った最新のPRをマージすると「それとその下のまだマージされていないすべての層を、一度の単一操作でランディング」できる。スタックの頂上を押せば、下に敷かれた層まで順に一緒に入る、という意味だ。逆に下層を先に個別マージすると、その上に残ったPRたちが「自動的にリベースされ、リターゲット (retarget) 」される。つまりBがmainへ先に入れば、もともとBをベースとしていたCは自動でベースブランチがmainへ切り替わり、その上でリベースされる。手でchainを編み直していた作業が消えるのは、まさにこの地点である。

三つ目に、既存のルールはそのまま生きている。ブランチ保護ルール (branch protection) と必須チェックはスタックの上でも同じく適用され、何がmainへ到達できるかを引き続き統制する。スタックドPRがレビューのゲートを迂回する裏口ではないという点は、導入抵抗を減らす設計である。アクセス経路も広い。ウェブ、CLI、モバイルに加え、コーディングエージェント向けのgh-stackスキルが併せて提供され、人ではなくエージェントが大きな作業を自ら複数層に割って上げるシナリオまで狙う。後で見るように、この「エージェントのためのスタック」という角度は、今回の発表のタイミングを読む一つの鍵である。

GitHubは発表にVercel(Next.jsチーム)、TED、WHOOP、そしてjQuery創始者の推薦文を添えた。彼らはスタックドPRのおかげで大きな機能を小さな変更に分けて送りやすくなったと語る。ただしこれらの引用は製品発表に載ったマーケティング文句であり、中立的な証拠ではなく宣伝として扱うのが正しい。実際の反応の肌理は、コミュニティの側がより正直に露わにする。HNスレッドのある参加者は、スカッシュマージ時にPRごとに再承認を要求したり、スタック全体を原子的にマージできなかったりと、初期実装にバグが少なくないという趣旨を指摘する。一方、Phabricator時代にこのワークフローに馴染んでいた別の参加者は、GitHubで長らく「恋しく思っていた」方式が戻ってきたという趣旨で歓迎する。要するにv1の完成度への不満と、方向そのものへの喜びが同居している。

深層 — なぜスタックなのか、そしてなぜgitではそれが難しいのか

スタックドdiffがなぜ存在するのかから押さえねば、今回の受容の意味はつかめない。出発点はレビューの経済学である。レビューの品質はdiffの大きさに反比例する。400行のPRと4,000行のPRを同じ集中度で読むレビュアーはいない。大きな変更一つを丸ごと上げれば、レビュアーは圧倒され、本当に危険な20行が退屈な2,000行の中に埋もれる。スタックドdiffの第一の論拠はここだ。一つの大きな目標を論理的に独立した小さな層へ割れば、各層は小さく、各層のレビューは深くなる。

第二の論拠は並列性である。大きな機能を単一ブランチに積めば、その機能がマージされるまで、その上の後続作業には手をつけにくい。スタックはこの鎖を断つ。Aを上げてレビューを受けている間に、その上にBを、さらにCを積んで作業を続けられ、AがマージされればB・Cが自動で追随して下りてくる。第三の論拠は原子的な取り消し (atomic revert) だ。各層が一つの完全な変更であれば、問題が起きたときにその層だけを正確に選んで戻せる。二十の事柄が入り混じった巨大コミットは、この精密な取り消しを不可能にする。整理すれば、スタックが取り除こうとする痛みは明確である。互いに依存するブランチの鎖を、下が変わるたびに手でリベースして維持する労働だ。

この方式の先例は長い。MetaのPhabricatorは arc diff とDifferentialでコミット単位のレビューとスタックを早くから扱い、Metaはのちにこれを継ぐバージョン管理システムSaplingをオープンソースで公開した。GoogleはCritiqueとGerritで「コミット一つがすなわちレビュー単位」というchange-per-commitモデルを社内標準とした。ghstack はMeta系のオープンソースツールで、各コミットを個別PRに割ってGitHubへ上げる。git-branchless とSaplingはスタック編集のための別ワークフローを提供する。そしてGraphiteはこれらの流れを商品化し、GitHubの上でスタックドPR体験を丸ごと提供するベンチャー投資を受けたスタートアップへと成長した。言い換えれば、GitHubが今回出したものは、すでに存在していた市場のネイティブ編入である。

ならば問いは裏返る。これほど古い良いアイデアを、世界最大のコードホスティングプラットフォームはなぜ今ごろ出したのか。答えの核心はgitのデータモデルにある。gitはブランチとコミットを知っている。しかし「このブランチはあのブランチの上に積まれたスタックの一層だ」という関係を、gitはネイティブで表現しない。スタックはgitの一級概念ではない。だからすべてのスタックツールは、gitの外に自分だけのメタデータを継ぎ足してスタックを真似る。ghstackはコミットメッセージに識別子を埋め、Graphiteは自前サーバーにスタック構造を保存し、GitHubの今回の実装はPRのベースブランチ指定とスタックマップでその関係を管理する。この「外に継ぎ足したメタデータ」こそが、スタックツール同士が互換せず、それぞれがロックイン (lock-in) を生む根本原因である。

まさにここで、今回の実装の設計選択が論争を呼ぶ。GitHubは変更の単位としてコミットではなくブランチ/PRを選んだ。HNスレッドのある参加者はこの点を突いて、GitHubがGerrit・Phabricatorがとうに確立したchange IDとバージョン追跡を導入しなかったという趣旨で批判する。change IDがあれば、リベースを経ても各変更のアイデンティティが保たれ、レビューコメントが消えず、リビジョン間のinterdiffレビュー(直前のレビュー以降に何が変わったかだけを見る)が可能になる。コミットをレビュー単位に置き、よく整えられたコミット履歴を重んじるgit文化と、ブランチを原子単位として扱うGitHubのPR文化が、ここで正面からぶつかる。これは単なる好みの争いではなく、レビューの連続性という実質に触れる問題である。

トレードオフはそれゆえ両側へ広がる。一方にはスタックそのものの費用がある。スタックは認知負荷を増やす。開発者は今やコードだけでなく、スタックの位相 — どの層がどこに依存し、何を先にマージすべきか — を頭の中に保たねばならない。下層で衝突が出れば、その上のすべての層へリベース衝突が連鎖 (cascade) し、自動リベースがあっても人が解かねばならない衝突は残る。ツールのロックインも実在する。HNでは gh stack CLIへの依存が、git自体を中心に標準化するよりGitHub従属を生むという趣旨の懸念が提起され、複数リポジトリ(polyrepo)にまたがるスタックを支援しない限界も指摘された。

もう一方には、より根本的な反論がある。本当に必要なのは精緻なPRの鎖なのか、という問いだ。トランクベース開発 (trunk-based development) の陣営は、そもそも大きな変更を何日もレビューの鎖で引きずらず、小さなコミットを頻繁にmainへ入れつつ未完成の機能はフィーチャーフラグ (feature flag) の後ろに隠せと言う。この観点からすればスタックは問題の解決ではなく迂回である。長く生きる分岐と大きなバッチレビューという根本原因を放置したまま、その上に管理ツールを載せる、というわけだ。むろん反対側の再反論も成り立つ。フィーチャーフラグはそれ自体がランタイムの複雑度と死んだコード経路、フラグ整理の負債を生み、互いに強く依存するリファクタリングはフラグで綺麗に分離できない。両陣営とも「小さく頻繁に」という目標は共有する。ただ、その目標に至る経路 — レビュー時点のスタックか、統合時点のフラグか — が分かれるだけだ。この分岐は好みではなく、チームのリリース構造と結合度に依る実証的な問題である。

展望 — スタックが利得になる瞬間と過剰になる瞬間

実務的な示唆は「スタックを使うか」ではなく「いつスタックが値するのか」へ絞るべきだ。スタックが明確に利得となる局面は二つある。第一は大きなリファクタリングである。インターフェースを変え、呼び出し側をすべて直し、古い経路を取り除く作業は、本質的に順序のある依存の鎖だ。こうした変更を単一PRで上げれば誰もまともに読めず、複数の独立PRへ無理に割れば互いにコンパイルされない。スタックはまさにこの隙間を埋める。第二は、互いに依存する連続作業を、前の作業のマージを待たずに続けねばならないときだ。前のPRがレビュー待ちのときに後の作業を止めなくてよいことは、レビューの遅延がそのまま開発の停滞になる大きな組織で、実質的なスループットの利得を与える。

逆にスタックが過剰になる局面も明白だ。互いに独立した小さな変更、一日のうちにレビューされマージされるPR、レビュアーと作成者が同じ二、三人しかいない小規模チームでは、スタックが与える利得より位相を管理する認知の費用が大きい。こういうときは、ただそれぞれを独立PRで上げて速くマージするほうがよい。ツールは問題があるときに導入すべきであって、ツールを正当化するために問題を膨らませてはならない。スタックドdiffを長く使ってきた組織が共通して言うのもこの点だ。スタックは万能ではなく、特定の形をした大きな作業のための専門ツールである。

生態系の次元での波紋はGraphiteに集中する。Graphiteの核となる価値提案は「GitHubにないスタック体験」だった。その欠落をGitHubがネイティブで埋め始めた以上、Graphiteの堀 (moat) は狭まる。とりわけスタックマップがGitHub自身のPR画面の中に住むという点は決定的だ。レビュアーが何もインストールする必要がないということは、別ツールを入れねばならないサードパーティが構造的に追いつきにくい地点だからである。ただしGraphiteには、GitHub v1がまだ通過中の数多のエッジケースをすでに解いた年季がある。先に見たスカッシュマージのバグ、change IDの不在、複数リポ未対応といった未成熟がGitHubの弱点なら、成熟度は当面サードパーティの防衛線となる。プラットフォームの所有者が機能をネイティブに吸収するとき、その上に立っていたスタートアップが被る典型的な圧迫 — いわゆる「プラットフォームに飲まれる」構図 — がここで繰り返される。

三つのシナリオで整理する。楽観はこうだ。GitHubがchange IDとinterdiff、複数リポ、安定した原子マージまで埋めれば、スタックドdiffは特権的ツールを備えたビッグテックの専有物から抜け出し、すべてのチームの基本ワークフローになる。MetaとGoogleが社内で享受していたレビュー文化が、業界標準として下りてくるという意味だ。悲観はこうだ。gitがスタックをネイティブで表現できない根本の限界がそのままである限り、GitHubの実装もまた外に継ぎ足したもう一層のメタデータにすぎず、リベースの連鎖衝突とツールのロックインという古い痛みを、名前だけ変えて再生産する。現実的な展望はその間だ。スタックドPRは大きなリファクタリングと依存の鎖という特定の問題で実質的な利得を与えつつ速く定着するが、トランクベース+フィーチャーフラグと競いながら共存し、Graphiteのようなサードパーティはネイティブがまだ及ばない成熟度と複数リポ・高度機能で上位市場に踏みとどまる、という図である。

一つの角度を添える。今回の発表がコーディングエージェント向けのgh-stackスキルを併せて載せたのは偶然ではない。HNでも、この機能が伝統的な開発よりAI生成コードのワークフローを狙ったものではないか、という趣旨の観察が出た。エージェントが大きな作業を自律的に複数層へ割って上げれば、人のレビュアーはその層を小さく分けて検討せねばならない。エージェントが生成するコードの量が増えるほど、そのコードを人が引き受けられる大きさへ切断する装置の需要も増える。スタックドPRの大衆化のタイミングは、レビュー対象の生産主体が人からエージェントへ移っていく流れと無縁ではない。

結論 — 大衆化なのか、ツール層の移動なのか

はじめの問いに戻る。スタックドdiffはついにGitHubで主流になるのか、それともgitのブランチモデルが表現できないものを無理やり支える弥縫策の拡散なのか。答えは二者択一ではない。どちらも真である。世界最大のプラットフォームがこのワークフローをネイティブに抱いたという事実だけで、スタックドdiffの大衆化はすでに引き返せない方向になった。MetaとGoogleが特権的な社内ツールとして享受していたレビュー文化が、インストールなしでレビュアーの画面の中へ入ってきたのは、本物の前進である。しかしその前進がgitの根本の限界を消したわけではない。スタックは依然としてgitの一級概念ではなく、GitHubの実装も外に継ぎ足したメタデータ層であるという点で、他のツールと本質は同じだ。ロックインの主体がサードパーティからプラットフォームへ移っただけで、ロックインそのものが消えたわけではない。

だから今回の受容の本当の意味は「問題が解けた」ではなく「論争の舞台が大きくなった」に近い。コミットかブランチか、スタックかトランク+フラグか、レビューの連続性をどう保証するかという問いは、いまやビッグテックの社内wikiではなく、すべてのチームの日常の上で扱われる。GitHubが遅れて到着したという事実は瑕ではなく、このワークフローが少数の実験を過ぎて検証された標準になった証しである。残るのは、各チームが自らの結合度とリリース構造を正直に見て、スタックが値する局面と過剰になる局面を見分けることだ。ツールが大衆化するほど、そのツールをいつ使わないかを知る判断が、より重要になる。

出典: