トランクベース開発

トランクベース開発とは

トランクベース開発 (Trunk-Based Development) は、開発者全員が trunk と呼ぶ 1 本のブランチ上で協調し、長寿命の開発ブランチを作る圧力に文書化された技法で抑える構成管理の手法である。参照定義を置く trunkbaseddevelopment.com は、この 1 本を Git の界では 2020 年以降 main と呼ぶと注記している。DORA は技術的なケイパビリティの 1 つとして整理し、各開発者が自分の作業を小さく分け、1 日に 1 回以上 trunk へマージする形と定義している。

対比されるフィーチャーブランチ方式は、複数人が数日から数週間ひとつのブランチに籠り、機能が完成してから trunk へ戻す。トランクベース開発のブランチは長くても数時間で終わる。両者を分けるのはブランチを使うかどうかではなく、統合されるまでに抱える変更の範囲と時間である。

「main へ直接コミットする手法」ではない

最も多い誤解が、トランクベース開発を main への直接コミットと同一視することだ。参照定義では、ごく小規模なチームが trunk へ直接コミットする形と、短命なフィーチャーブランチを立ててプルリクエストでレビューを受ける形の両方が認められている。条件は、そのブランチが短命であり、1 つの開発環境で作られた変更に収まっていることである。判定軸はブランチの有無ではなく、ブランチが trunk から離れている時間と統合の頻度にある。

短命ブランチの役割も限定されている。コードレビューとビルド確認 (CI) のために置くもので、そこで成果物を作って配布する場所ではない。長さの上限は、継続的インテグレーションが求める「全員が 24 時間に 1 回以上 trunk へコミットする」を満たせる範囲と考えればよい。レビュー待ちで 2 日置かれたブランチは、呼び名が短命でも長寿命ブランチと同じ問題を生む。レビューが数時間で返る運用は、この手法の付帯条件ではなく前提条件である。

Git Flow との違い

Git Flow は develop / release / hotfix といった長期ブランチを併走させ、リリースの節目で統合する。統合の間隔が長いほど、その間に他人が動かした行との差分が積み上がり、マージの難度がブランチの寿命に対して直線的にではなく増えていく。

Git Flow の原型は Vincent Driessen が 2010 年 1 月に公開したブランチモデルである。著者は 2020 年 3 月の追記で、継続的デリバリーを行うチームにはより単純なワークフロー (GitHub Flow など) を勧め、一方で明示的にバージョンを持ち、複数のバージョンを世に出したまま保守する必要があるソフトウェアには依然として適合すると書いている。選択は新旧の優劣ではなく、保守すべきリリースが 1 系統か複数系統かで決まる。

進め方

1 つの変更が trunk に入るまでの流れは次の 5 段になる。

1. main から短命ブランチを作成
2. 小さな変更をコミット (数時間以内)
3. PR を作成、レビュー
4. main にマージ
5. CI/CD で自動デプロイ

❌ 避けるべき: feature/big-refactor (2 週間)
✅ 推奨: fix/validation-error (2 時間)

小さな変更の原則

1 つの PR には 1 つの意図の変更だけを含める。差分は数百行を上限の目安にする。これを超えるとレビュアーが全体の筋を追えなくなり、指摘が命名や書式といった表面の話に寄っていく。リファクタリングと機能追加を同じ PR に混ぜると、振る舞いが変わった行がどれか判別できなくなるので必ず分ける。各 PR にテストを含め、PR 単体で検証可能にする。

分割できない大きな変更には 2 つの逃げ道がある。1 つは抽象化を挟んで新旧の実装を並走させ、呼び出し先を段階的に切り替える方法 (Branch by Abstraction) で、もう 1 つは未完成の経路を閉じたまま main へ入れる方法である。どちらも「変更が大きいから長寿命ブランチが必要」という結論を回避するための技法として、参照定義に併記されている。

成立に必要な条件

trunk が常にデプロイ可能でなければ、マージを頻繁にしても事故の頻度が上がるだけになる。以下はいずれも、壊れた状態が trunk に残る時間をゼロに近づけるための条件である。

未完成の機能を閉じたまま main へ入れる仕組みがフィーチャーフラグで、分類ごとの寿命と消し忘れの管理はそちらで扱う。フラグを持たないまま短命ブランチだけ導入すると、完成まで統合できない変更が長寿命ブランチに逆戻りする。

導入の判断基準

着手はブランチ運用の変更からではない。判断は 3 点で足りる。trunk が壊れたときにその日のうちに気づいて戻せる自動テストとビルドがあるか。レビューが数時間で返る体制か。保守するリリースが 1 系統に絞れるか。欠けたものを埋めないまま短命ブランチだけ導入すると、統合の頻度が上がった分だけ壊れた trunk の前で手が止まる人が増える。逆に 3 点が揃っているなら、ブランチ寿命を短くするのは運用ルールの変更だけで済む。