ブランチ戦略

この章では、チーム開発で使われる代表的なブランチ戦略と、プロジェクトに合った戦略の選び方を学びます。

ブランチ戦略とは

ブランチ戦略は、チームがどのようにブランチを作成・管理・マージするかのルールです。適切な戦略を選ぶことで、開発の効率化とコードの品質維持が可能になります。

なぜブランチ戦略が必要か

混乱の防止: 誰が何をしているか明確に
品質の維持: 適切なレビューとテストの確保
リリース管理: 計画的なデプロイが可能に
トラブル対応: 問題発生時の対処が明確に

Git Flow

概要

2010年にVincent Driessenが提唱した、最も有名なブランチモデルです。

ブランチ構成

main（本番）
  │
  └─ develop（開発統合）
       │
       ├─ feature/xxx（機能開発）
       ├─ release/v1.0（リリース準備）
       └─ hotfix/xxx（緊急修正）

ブランチ	役割	ライフサイクル
`main`	本番環境と同期	永続
`develop`	開発の統合ブランチ	永続
`feature/*`	機能開発	短期（PR後削除）
`release/*`	リリース準備	短期（リリース後削除）
`hotfix/*`	緊急バグ修正	短期（修正後削除）

ワークフロー

1. feature ブランチを develop から作成
2. 機能を開発してコミット
3. develop にPR → レビュー → マージ
4. リリース時に release ブランチを作成
5. テスト・バグ修正
6. main と develop にマージ
7. main にタグを付けてデプロイ

メリット・デメリット

メリット	デメリット
厳格なリリース管理	複雑で学習コストが高い
本番環境の安定性	ブランチが多くなりがち
緊急対応のフローが明確	CI/CDとの相性がやや悪い

向いているプロジェクト

定期リリース（月1回など）のソフトウェア
複数バージョンの並行サポート
大規模チームでの開発

GitHub Flow

概要

GitHubが提唱する、シンプルなブランチモデルです。

ブランチ構成

main（本番）
  │
  ├─ feature-a
  ├─ feature-b
  └─ bugfix-c

6つのルール

main は常にデプロイ可能な状態
新しい作業は main からブランチを作成
定期的にリモートにプッシュ
フィードバックが欲しいときにPRを作成
マージは必ずPRレビュー後
マージ後すぐにデプロイ

ワークフロー

1. main からブランチを作成
2. 作業してコミット・プッシュ
3. PRを作成
4. レビュー・修正
5. マージ
6. 自動デプロイ

メリット・デメリット

メリット	デメリット
シンプルで理解しやすい	複雑なリリース管理には不向き
CI/CDとの相性が良い	大規模チームでは混乱の可能性
素早いデリバリーが可能	本番の安定性に注意が必要

向いているプロジェクト

Webサービス（継続的デプロイ）
小〜中規模チーム
アジャイル開発

Trunk Based Development

概要

Google や Facebook が採用する、main（trunk）を中心としたモデルです。

ブランチ構成

main（trunk）
  │
  ├─ short-lived-branch-a（数時間〜数日）
  └─ short-lived-branch-b

基本原則

短命ブランチ: 1〜2日以内にマージ
小さなPR: レビューしやすいサイズ
フィーチャーフラグ: 未完成機能を本番に含める
頻繁なマージ: 1日に何度もマージ

ワークフロー

1. main から短命ブランチを作成
2. 小さな単位で開発
3. 1〜2日以内にPR・マージ
4. フィーチャーフラグで機能を制御
5. 完成したらフラグを有効化

フィーチャーフラグの例

// 未完成機能を隠す
if (featureFlags.newCheckout) {
  showNewCheckout();
} else {
  showOldCheckout();
}

メリット・デメリット

メリット	デメリット
マージコンフリクトが少ない	フィーチャーフラグの管理が必要
継続的インテグレーション	チームの成熟度が求められる
素早いフィードバック	自動テストの充実が前提

向いているプロジェクト

大規模Webサービス
成熟したエンジニアリング組織
高頻度デプロイ環境

戦略の比較

一覧表

項目	Git Flow	GitHub Flow	Trunk Based
複雑さ	高	低	中
ブランチ数	多い	少ない	最小限
リリース頻度	低〜中	高	非常に高
チームサイズ	大規模向け	小〜中規模	成熟チーム
学習コスト	高い	低い	中程度

選択フローチャート

Q: リリースは定期的？（週1回以下）
├─ Yes
│  Q: 複数バージョンのサポートが必要？
│  ├─ Yes → Git Flow
│  └─ No → GitHub Flow（release ブランチ付き）
│
└─ No（継続的デプロイ）
   Q: チームの成熟度は？
   ├─ 高い（自動テスト充実、経験豊富）→ Trunk Based
   └─ これから → GitHub Flow

ハイブリッドアプローチ

GitHub Flow + Release Branch

GitHub Flow をベースに、リリース用ブランチを追加：

main
  │
  ├─ feature/xxx
  └─ release/v1.0（リリース前の最終調整）

Git Flow 簡略版

develop ブランチを省略：

main
  │
  ├─ feature/xxx
  ├─ release/v1.0
  └─ hotfix/xxx

中級者向けTips

ブランチ戦略の文書化

チームの CONTRIBUTING.md や Wiki に記載：

# ブランチ戦略

## ブランチ命名規則
- feature/ISSUE-123-add-login
- bugfix/ISSUE-456-fix-validation
- hotfix/critical-security-fix

## ワークフロー
1. Issue を確認
2. main からブランチを作成
3. 実装・テスト
4. PR を作成（テンプレート使用）
5. レビュー後マージ

ブランチ保護との組み合わせ

戦略に合わせて保護ルールを設定：

Git Flow:
- main: 厳格（release/hotfix からのみマージ可）
- develop: レビュー必須

GitHub Flow:
- main: レビュー必須、ステータスチェック必須

戦略の移行

Git Flow から GitHub Flow への移行例：

# 1. develop の変更を main にマージ
git checkout main
git merge develop

# 2. develop ブランチを削除
git branch -d develop
git push origin --delete develop

# 3. ブランチ保護ルールを更新
# 4. チームに周知

まとめ

戦略	特徴	向いている組織
Git Flow	厳格なリリース管理	定期リリース、大規模
GitHub Flow	シンプル、CI/CD向き	継続的デプロイ、小〜中規模
Trunk Based	超短命ブランチ	成熟チーム、高頻度デプロイ

選択のポイント

シンプルに始める: 迷ったら GitHub Flow から
チームに合わせる: 成熟度と規模を考慮
進化させる: 必要に応じて戦略を調整
文書化する: ルールを明文化して共有

次の章では、ブランチ命名規則について学びます。

Q1. Git Flowの永続ブランチはどれですか?

Q2. GitHub Flowの6つのルールに含まれないものはどれですか?

Q3. Trunk Based Developmentの特徴として正しいものはどれですか?