Stacked PRの、何が新しいのか

Transcript

1. 2026年08月12日（水） Stacked PRの、何が新しいのか GitHub Stacked Pull Requests ／ 手で積むのと何が違うか 赤神 青空
2. ▪大きなPRを切りたい理由が、前より切実になっている 書く速さは上がった。読む速さは上がらない コードを書く速さが上がった結果、律速がレビュー帯域に移った。 これまでの詰まり 書く人が足りない。だから生成を速くした。 いまの詰まり 読む人が足りない。生成を速くしても効かない。 「PRを小さく切る」の価値が上がっている。ではなぜ、今までやらなかったのか。 今ココ 導入 2/13
3. ▪2026年7月30日に出た機能の話をする前に 積むこと自体は、前からできた baseを指定するだけなので、GitHubの新機能を待つ必要はなかった。 全部 main を向けて独立に出す 依存があると成立しない 上の層の差分に、下の層の変更が混ざる ブランチを積んで base を指定する 依存は表現できる。手でもできた Meta や Google は10年以上これをやっている 今ココ 経緯 3/13
4. ▪「積む」が実際にやっていること ブランチは全部持つが、PRは自分の層だけ見せる feature- feature- feature- C A main B D E 含むコミット PRの差分 A‧B‧C‧D‧E E だけ （PR# ） A‧B‧C‧D D だけ （PR# ） A‧B‧C C だけ （PR# ） A‧B — base が一つ下を向くので、見えるのは自分の分だけになる 今ココ 経緯 4/13
5. ▪手で積んだときに、いちばん面倒だったところ 下を1回直すと、上が全部やり直しになる ⼿でブランチを積んでいたころ 指摘を反映する feature- の C → C′ feature- を rebase D → D′ ハッシュが書き換わる feature- を rebase E → E′ 下が動いた分だけ巻き添え force push × さらに feature- がマージされたら feature- の base を⼿で付け替え これを層の数だけ、レビューのラウンドごとに繰り返す。3層×2ラウンドで「1個の⼤きなPRのほうが楽だったのでは」となる Stacked PRs 指摘を反映する feature- の C → C′ 上の層はカスケードで追随する gh stack rebase / sync 画⾯のボタンからサーバ側で実⾏することもできる マージ後の付け替えも⾃動 feature- が落ちると feature- の base は main になる ⼿元のブランチだけは置いていかれる。ハッシュが変わっているので gh stack sync で追いつく 上：層の数だけリベースして force push／下：伝播も付け替えも自動になった 今ココ 経緯 5/13
6. ▪機能として何が新しいのか 外れたのは、分割のコストのほう ✕ 手で積んでいたころ 下の層を直すたび、上を全部リベース リベースでハッシュが変わり、さらに上も巻き添え 下がマージされたら、上のbaseを手で付け替え 3層×2ラウンドで「大きいPRのほうが楽」になる ◯ いま 下の層が変わると、上は自動で追随する 下がマージされると、上のbaseは自動で付け替わる 上のPRをマージすると、下の未マージ層も一緒に着地 GitHub側がStackを1つの単位として持っている 分割の利益を、リベースの運用コストが食い潰していた。だから選ばれなかった。 今ココ 経緯 6/13
7. ▪ここは手動スタックでは作れなかった 中段のPRも、mainと同じ基準で審査される 全PRが、直接のbaseではなく スタックのbase（＝main）に対して評価される。 手で積むと 中段のbaseは feature-1 。mainのブランチ保護は効か ない。 いまは 必須レビュー・必須チェック・CODEOWNERSが全層に効 く。 便利になった話ではなく、手では用意できなかった保証がついた話です。 今ココ 何が新しいのか 7/13
8. ▪init で始めて、add 3層のスタックを作って出す で重ねて、submit で出す bash gh extension install github/gh-stack gh stack init feature/table # 1段目 git add . && git commit -m "テーブル定義を追加" gh stack add -Am "サービス層を追加" feature/service gh stack add -Am "APIを追加" feature/api gh stack submit 今ココ 何が新しいのか # push・PR作成・Stack化 8/13
9. ▪コストが外れると、選択肢としての意味が変わる 1人で3回見るか、3人で1回ずつ見るか 1本の⼤きなPR 1,000⾏ 全領域が1つに⼊る レビュアーA スキーマを⾒る ロジックを⾒る UIを⾒る 完了 同じ⼈が順番に⾒るので、他の誰も先に進めない 完了 3層のStack 各層 300⾏前後 層ごとに担当を 割り当てられる スキーマを⾒る レビュアーA ロジックを⾒る レビュアーB UIを⾒る レビュアーC 依存が本物のときだけ効く。並⾏して作れただけの変更を積むと、 マージ段階でまた直列に戻る 上：1人が順番に見るので後続が全部待つ／下：層ごとに担当を分けて同時に見る 今ココ 効きどころ 9/13
10. ▪着手前にきれいに分けられる人は、たぶんいない 切り分けは、作業しながら見つかる 見つける → ついでのバグ修正を 切り離す 別で出したくなる 分割は設計ではなく発見 着手前に正しい切り方は決まらない。触 ってから分かる。 差し込む gh stack modify で 下の層として挿入する 手だと、これが最悪だった → 自動で追随 途中に層を入れると、上を全部リベース し直すことになる。 積み直る 上の層が その上に乗り直す だから後回しにできる 分けるかどうかを、出す直前まで決めな くてよくなる。 挿し込んだとき実際に何が起きるかは、まだ手元で確かめていない 今ココ 効きどころ 10/13
11. ▪自動化されたのは機械的な部分だけ 入れたあとに効いてくるコスト リベースは自動でも、「読み直し」は自動にならない。 01 02 03 全層で workflow が走る。metadata で 間引く設計が要る 技術的なリベースは自動でも、影響を受 けた層は再レビューが要る 同一リポジトリの直列のみ。並べ替えは CLIからしかできない CI費用が段数倍 今ココ 制約 下を直すと上が揺れる forkと分岐は不可 11/13
12. ▪4月から7月で9リリース。public 消えて、戻ってきたコマンドがある preview は仕様が動くという意味 gh stack merge 5月、削除 は一度削除されてから、復活した。 ブラウザを開くだけのプレースホルダだった。マージAPI待 ちで外された。 7月、復活 v0.1.0 でアトミックな一括マージとして実装され直した。 ほかにも、内部APIから公開APIへの移行や、引数の削除が入っています。 今ココ 制約 12/13
13. ▪「うちも前からブランチ切ってた」から先の話 持ち帰り 01 手法は新しくない。外れたのは運用コスト できるかどうかではなく、割に合うかどうかが変わった。だから今から選択肢になる。 02 中段のPRもmain基準で審査される 手で積んだスタックには無かった保証。設定変更なしで既存のルールが全層に効く。 03 まず個人リポジトリで3層つくる 途中の層を直したとき、modify で層を挿し込んだときに何が起きるかを見る。 分割できない変更に出会ったら、設計が絡まっているサインかもしれない 今ココ まとめ 13/13