補足 2. ブランチ運用戦略
ブランチ戦略の核心は難しくありません。 作業を小さく分け、早く統合することです。
チームごとに名前は違っても、実際にはこの共通原則の上に Git Flow、GitHub Flow、GitLab Flow、TBD のような運用ルールを重ねて使うことが多いです。
どの戦略にも共通する基本習慣
- 基準の道（main）を常に安定した状態で保つ。
- 作業ごとに短いブランチを 1 本ずつ作る。
- 終わったらすばやく main に統合する。
- 緊急修正は別ブランチで短く処理する。
どの戦略を選んでも、ブランチが長く開きすぎると結局 互いに別方向へ離れていき、あとで統合するコストが大きくなります。 下の 2 つのパターンは、多くのチームが共通して守ろうとする基本習慣です。
GitHub Flow と TBD はこの習慣がより直接的に見えやすく、 Git Flow もブランチの種類が多いだけで、内側の運用感覚はそれほど離れていません。
図 B2-1. 短い作業ブランチをすばやく統合するパターン
ブランチが長く開きっぱなしでなければ、衝突の危険は大きく下がります。
図 B2-2. 緊急修正ブランチの運用
緊急修正は短く処理してまず main に反映し、そのあと必要な道へもう一度配り直します。
代表的な戦略の比較
下の戦略は正解を競うものではなく、チームの配布速度や検収のやり方によって重みが変わる運用方式です。 タブを押して、それぞれの戦略の説明とグラフ例を一緒に確認してください。
Git Flow
main と develop のように長く維持する基準の道を置き、 機能作業は develop 側へ集めてから、配布直前に release で仕上げる方式です。
- 配布周期がはっきりしていて、アート確認や QA 期間を別に置くチームに向いています。
- 機能作業、配布準備、緊急修正の道がはっきり分かれているので、役割を分けやすくなります。
- その代わりブランチ数が増えるので、小さなチームや高速反復にはやや重く感じられることがあります。
図 B2-3. Git Flow の例
feature は develop へ、release は配布準備用、hotfix は main 基準の緊急修正用として別々に動きます。
GitHub Flow
main ひとつを中心に短い作業ブランチを作り、 レビューしやすい 1 まとまりに整えてから PR を通して main へ統合する方式です。
- 要点は 1 本のブランチがレビュー可能な作業単位になることです。
- 小さく作って頻繁に統合するチーム、配布回数が多いチーム、道具が main 中心に組まれているチームに向いています。
- その代わり main を常に配布可能に近い状態で保つ必要があり、レビューが遅れるとブランチがすぐ長くなります。
図 B2-4. GitHub Flow の例
feature ブランチがレビューの 1 まとまりの間だけ生きていて、PR が終わると main に統合されるパターンです。
GitLab Flow
main に作業を集めつつ、staging や production のような環境ブランチを別に持ち、 どの結果が検収中で、どの結果が実運用中なのかを分けて運用する方式です。
- 要点は 作業ブランチだけでなく配布環境そのものもブランチとして追跡することです。
- 内部検収ビルドと実運用ビルドを分ける必要があるチーム、環境ごとに承認手順があるチームに向いています。
- その代わり環境ブランチ同士で何が先に上がったかの規則が崩れると、管理はすぐ複雑になります。
図 B2-5. GitLab Flow の例
feature を main に集めたあと、staging で検収ビルドを作り、確認が終われば production に上げるパターンです。
TBD
TBD は Trunk Based Development の略です。 先ほど見た基本習慣をもっとも強く適用し、trunk（main）へ非常に高い頻度で戻って統合する方式です。
- 要点は ブランチをほとんど滞在しない仮の通路のように使うか、チームによっては省略することさえある点です。
- 作業をとても小さく分け、1 日のうちに何度も trunk へ戻れるチームに向いています。
- その代わり未完成の作業をそのまま見せないための露出制御と、素早い検証習慣が一緒に必要です。
図 B2-6. TBD の例
1〜2 個の Commit ほどの短い作業が、数時間のうちに main へ戻ってくる流れです。