第4章ブランチ戦略

ブランチの作り方やマージのやり方を学んだところで、
この章では一歩引いて 「チームとしてブランチをどう運用するか」 を考えましょう。

ブランチ戦略は、チームの規模・リリースサイクル・プロダクトの特性によって最適解が変わります。
管理者として 「なぜこの戦略なのか」を説明できる ことが重要です 🗺️

4.1 代表的なブランチ戦略

Git Flow

Git Flow は、2010年に Vincent Driessen が提唱した戦略で、
リリースサイクルが明確な プロジェクトに適しています。

%%{init: { 'gitGraph': { 'showCommitLabel': true, 'mainBranchName': 'main' } } }%%
gitGraph
    commit id: "v1.0.0" tag: "v1.0.0"
    branch develop
    checkout develop
    commit id: "dev-1"
    branch feature/login
    checkout feature/login
    commit id: "feat-1"
    commit id: "feat-2"
    checkout develop
    merge feature/login id: "merge-feat"
    branch release/1.1
    checkout release/1.1
    commit id: "rc-fix"
    checkout main
    merge release/1.1 id: "v1.1.0" tag: "v1.1.0"
    checkout develop
    merge release/1.1 id: "merge-rc"
    checkout main
    branch hotfix/security
    commit id: "hf-1"
    checkout main
    merge hotfix/security id: "v1.1.1" tag: "v1.1.1"
    checkout develop
    merge hotfix/security id: "merge-hf"

ブランチの役割

ブランチ	寿命	役割
`main`	永続	本番環境のコード。常にリリース可能
`develop`	永続	開発の統合ブランチ。次のリリースの準備
`feature/*`	一時的	新機能の開発。 develop から分岐し develop にマージ
`release/*`	一時的	リリース準備。 develop から分岐し main と develop にマージ
`hotfix/*`	一時的	緊急修正。 main から分岐し main と develop にマージ

フローの流れ

flowchart TD
    A["① feature ブランチで開発"] --> B["② develop にマージ"]
    B --> C["③ release ブランチを作成"]
    C --> D["④ テスト・バグ修正"]
    D --> E["⑤ main にマージ + タグ付け"]
    E --> F["⑥ develop にもマージ"]

    G["🚨 本番バグ発見"] --> H["hotfix ブランチを作成"]
    H --> I["main と develop にマージ"]

    style A fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style E fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style G fill:#FFEBEE,stroke:#E53935,color:#B71C1C

メリット・デメリット

✅ メリット	❌ デメリット
リリースの管理が厳密にできる	ブランチが多く運用が複雑
本番とリリース準備を分離できる	マージが頻繁に発生する
バージョン管理がしやすい	リリースサイクルが遅くなりがち
ホットフィックスの手順が明確	小規模チームにはオーバースペック

GitHub Flow

GitHub Flow は、GitHub 社が提唱した シンプルな 戦略です。
継続的デリバリー を実践するチームに広く採用されています。

%%{init: { 'gitGraph': { 'showCommitLabel': true, 'mainBranchName': 'main' } } }%%
gitGraph
    commit id: "init"
    branch feature/login
    checkout feature/login
    commit id: "feat-1"
    commit id: "feat-2"
    checkout main
    merge feature/login id: "PR #1"
    branch fix/header
    checkout fix/header
    commit id: "fix-1"
    checkout main
    merge fix/header id: "PR #2"
    branch feature/profile
    checkout feature/profile
    commit id: "feat-3"
    commit id: "feat-4"
    checkout main
    merge feature/profile id: "PR #3"

ルール

たった6つのルール で運用できます。

flowchart TD
    R1["① main は常にデプロイ可能"]
    R2["② 作業は main から
ブランチを切る"]
    R3["③ ブランチ名は
わかりやすく"]
    R4["④ こまめに push する"]
    R5["⑤ Pull Request で
レビューを受ける"]
    R6["⑥ レビュー後に
main にマージ → デプロイ"]

    R1 --> R2 --> R3 --> R4 --> R5 --> R6

    style R1 fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style R5 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style R6 fill:#F3E5F5,stroke:#8E24AA,color:#4A148C

メリット・デメリット

✅ メリット	❌ デメリット
シンプルで覚えやすい	リリースの細かい管理が難しい
CI/CD と相性が良い	複数バージョン管理には向かない
デプロイ頻度が高くなる	main の品質管理が重要
ブランチの迷いが少ない	大規模チームでは競合が増えやすい

Trunk-Based Development

Trunk-Based Development (TBD) は、
全員がメインブランチ（trunk）に直接コミットする、または
非常に短命なブランチ で開発する戦略です。

%%{init: { 'gitGraph': { 'showCommitLabel': true, 'mainBranchName': 'trunk' } } }%%
gitGraph
    commit id: "A"
    commit id: "B"
    branch short-lived/feat-1
    checkout short-lived/feat-1
    commit id: "feat"
    checkout trunk
    merge short-lived/feat-1 id: "merge"
    commit id: "C"
    commit id: "D"
    branch short-lived/fix-1
    checkout short-lived/fix-1
    commit id: "fix"
    checkout trunk
    merge short-lived/fix-1 id: "merge2"
    commit id: "E"

重要なルール

ルール	説明
ブランチは 1〜2日以内にマージ	長命ブランチを作らない
フィーチャーフラグで未完成機能を隠す	コードは main にあるが、ユーザーには見えない
CI が必須	trunk が常に壊れていないことを保証
全員が毎日 trunk に統合	「大きなマージ」を避ける

フィーチャーフラグとは？

未完成の機能をコードとしては main にマージしつつ、
フラグで表示/非表示を切り替える テクニックです。

// フィーチャーフラグの例
if (featureFlags.newLoginPage) {
    renderNewLoginPage();
} else {
    renderOldLoginPage();
}

メリット・デメリット

✅ メリット	❌ デメリット
マージの競合が最小限	フィーチャーフラグの管理が必要
常に最新のコードで開発	CI/CD の整備が前提
デプロイが非常に高速	高い規律とスキルが求められる
Google / Facebook 等の大手が採用	小さな変更の積み重ねが必要

4.2 プロジェクト規模に応じた戦略の選定

比較表

項目	Git Flow	GitHub Flow	Trunk-Based
複雑さ	高い	低い	中〜高
ブランチ数	多い	少ない	最小限
リリース管理	◎ 厳密	△ シンプル	○ フラグで管理
デプロイ頻度	低〜中	高い	非常に高い
CI/CD 依存度	中	高	非常に高い
チーム規模	中〜大	小〜中	小〜大
学習コスト	高い	低い	中

選定フローチャート

flowchart TD
    START["🤔 どのブランチ戦略？"]
    Q1{"リリース日が
決まっている？"}
    Q2{"CI/CD パイプラインは
整備されている？"}
    Q3{"フィーチャーフラグを
導入できる？"}
    Q4{"チーム規模は？"}

    START --> Q1
    Q1 -- "はい" --> GF["📋 Git Flow
リリース管理を厳密に"]
    Q1 -- "いいえ" --> Q2
    Q2 -- "いいえ" --> GH1["🔄 GitHub Flow
まずはシンプルに"]
    Q2 -- "はい" --> Q3
    Q3 -- "いいえ" --> GH2["🔄 GitHub Flow
十分高速に開発できる"]
    Q3 -- "はい" --> Q4
    Q4 -- "小〜中規模" --> GH3["🔄 GitHub Flow
or Trunk-Based"]
    Q4 -- "大規模" --> TB["🚀 Trunk-Based
スケーラブルに"]

    style GF fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style GH1 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style GH2 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style GH3 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style TB fill:#E8F5E9,stroke:#43A047,color:#1B5E20

よくある組み合わせ

実は多くのチームが「純粋な○○ Flow」ではなく、
カスタマイズした独自のフロー を使っています。

プロジェクト例	採用が多い戦略
Web アプリ（SaaS）	GitHub Flow + 自動デプロイ
モバイルアプリ	Git Flow（審査のため）
OSS ライブラリ	Git Flow or GitHub Flow
マイクロサービス	Trunk-Based
受託開発（納品型）	Git Flow
スタートアップ初期	GitHub Flow（シンプル重視）

大切なのは 「チーム全員が理解して、同じルールで動けること」 です。
どんなに優れた戦略でも、守られなければ意味がありません。

戦略を決めたらやること

ブランチ戦略を決定したら、以下を整備しましょう。

flowchart LR
    A["① 戦略の文書化
README or Wiki"]
    B["② Branch Protection
Rules の設定"]
    C["③ CI/CD の構築"]
    D["④ チームへの説明"]
    E["⑤ 定期的な見直し"]

    A --> B --> C --> D --> E
    E -. "改善" .-> A

    style A fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style B fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style C fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style D fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style E fill:#FFF9C4,stroke:#F9A825,color:#F57F17

やること	内容
文書化	どのブランチから分岐するか、マージ先はどこか、命名規則は何か
Branch Protection	main / develop への直接 push を禁止、レビュー必須など（第6章で詳しく解説）
CI/CD	PR 作成時にテスト・リント自動実行（第7章で詳しく解説）
チーム説明	オンボーディング資料として整備、ハンズオンの実施
定期見直し	チームの成長やプロダクトの変化に合わせて調整

まとめ

戦略	一言で言うと	向いている場面
Git Flow	「きっちり管理」	リリース計画が明確なプロジェクト
GitHub Flow	「シンプル＆高速」	Web アプリ、小〜中規模チーム
Trunk-Based	「最速デリバリー」	CI/CD が成熟したチーム

第4章 ブランチ戦略

4.1 代表的なブランチ戦略

Git Flow

ブランチの役割

フローの流れ

メリット・デメリット

GitHub Flow

ルール

メリット・デメリット

Trunk-Based Development

重要なルール

フィーチャーフラグとは？

メリット・デメリット

4.2 プロジェクト規模に応じた戦略の選定

比較表

選定フローチャート

よくある組み合わせ

戦略を決めたらやること

まとめ

第4章ブランチ戦略