09. ブランチ戦略

3 つの代表戦略

GitHub Flow（推奨）

GitHub 公式が提唱するシンプル戦略。ほとんどの Web サービスと IaC リポジトリはこれで足りる。

main ─────────────●─────────●─────────●─→
                  ↑         ↑         ↑
       feature/A ─┘  feature/B─┘  feature/C─┘

1. main から feature ブランチを切る
2. commit して push、Pull Request を出す
3. CI 通過 + レビュー承認 → main にマージ
4. main へのマージ ＝ リリース（CI が apply）

長所

• シンプル: 誰でも理解できる、新メンバーのオンボーディングが速い
• main が常にデプロイ可能 → ロールバックも main から戻すだけ
• 長寿命ブランチがないので merge conflict が少ない

短所

• main = 本番、なので CI/CD と環境保護をしっかり組む必要
• 大規模な機能を「途中の状態」で main に入れる場合は feature flag が必要

Trunk-Based Development

GitHub Flow よりさらに先進的。ブランチを 1〜2 日で消す、main へ高頻度マージ。Google や Facebook が採用。

main ─●─●─●─●─●─●─●─→ (1日に何回もマージ)
        feature/A は 1〜2日で消える

• feature flag を駆使して未完成機能を main に乗せる
• テストカバレッジが高く、自動デプロイが整っている前提
• 巨大 PR が出にくくなる（小さく早く）

IaC でも有効。「巨大な変更を 1 PR で」より「小さく毎日 apply」の方が事故が少ない。

Git Flow（多くの IaC には過剰）

2010 年代に流行った戦略。複数の長寿命ブランチを持つ。

main      ─────●─────────●─────────●  (タグ付きリリース)
develop   ──●──┴──●──●──●┴──●──●──●┴
feature   ─┘   ┘  ┘ ┘   ┘  ┘ ┘ ┘
release         └──────●           (安定化)
hotfix              └──●           (本番修正)

• パッケージ／組み込み／企業向けで「v1.0、v1.1」とリリースを区切る場合に向く
• SaaS / 継続デプロイのプロジェクトには 過剰すぎる（GitHub Flow の方が早い）
• IaC では複数の長寿命ブランチ間で state を共有しにくい問題が出る

IaC で何を選ぶか

結論: GitHub Flow が第一候補。Trunk-Based は熟練したチームで、Git Flow は基本選ばない。

環境ブランチ vs 環境ディレクトリ

「dev / stg / prd ごとにブランチを作る」誘惑があるが、強く非推奨。

# NG: ブランチで環境分離
main         ───────────────●──→  (これが prd)
stg          ───────●─●─●─●─→
dev          ───●─●─●─●─●─●─→

# OK: ディレクトリで環境分離（02 章）
main ─────●─●─●─●─●─→
        envs/
        ├── dev/
        ├── stg/
        └── prd/

理由:

• 長寿命ブランチが増え merge conflict が常態化
• 「dev で試した変更」を stg / prd へ「cherry-pick」する手作業が事故源
• 共通モジュールの変更を全環境に伝播させるのが面倒

ディレクトリ分離なら 1 PR で「dev で試 → stg → prd」を順に同じ main で apply できる。02 章参照。