Git ブランチ戦略とワークフロー——GitFlow, GitHub Flow, トランクベース開発

この記事の内容

Git ブランチ戦略は、チーム開発の生産性とコード品質に直結します。本記事では、主要なブランチ戦略の特徴から、適切な選択基準までを解説します。

Git ブランチ戦略の重要性

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

❌ ブランチ戦略なしのチーム
・誰でも自由にブランチ作成
・マージ競合が頻発
・本番環境へのデプロイが不安
・「誰のコードか分からない」状態

✅ ブランチ戦略ありのチーム
・一貫したワークフロー
・予測可能なリリース
・品質保証のプロセス明確
・責任の所在が明確

良いブランチ戦略の条件

1. シンプルさ——チーム全員が理解・遵守可能
2. スケーラビリティ——チーム規模拡大にも対応
3. 品質保証——テスト・レビュープロセスの統合
4. スピード——フィードバックループが短い

主要なブランチ戦略 3 選

1. GitFlow（ギットフロー）

最も伝統的で、厳格なモデルです。

main (本番ブランチ)
  │
  ├─→ release/v1.0 ────┐
  │                    ▼
  ├─→ develop ─────→ main
  │     │
  │     ├─→ feature/user-auth
  │     ├─→ feature/payment
  │     └─→ feature/dashboard
  │
  └─→ hotfix/bug-fix (本番用修正)

5 つのブランチ類型

特徴

向いているプロジェクト

• ✅ 大規模チーム（10 名以上）
• ✅ 複数のバージョンを並行メンテナンス
• ✅ 厳格なリリース管理が必要
• ✅ 組み込みシステム、エンタープライズ

向いていないプロジェクト

• ❌ 小規模スタートアップ
• ❌ 頻繁なデプロイ（1 日数回）
• ❌ SaaS / Web サービス

2. GitHub Flow

GitHub が推奨する、シンプルでモダンなモデルです。

main（常にデプロイ可能）
  │
  ├─→ feature-branch
  │     │
  │     ├─→ コミット
  │     ├─→ プルリクエスト
  │     ├─→ レビュー
  │     ├─→ テスト（CI）
  │     │
  │     ▼
  └──── main にマージ → デプロイ

基本ルール

1. main ブランチは常にデプロイ可能
2. 新機能はブランチを切る（feature-name）
3. プルリクエストを作成
4. レビューと CI を通過
5. main にマージして即時デプロイ

特徴

向いているプロジェクト

• ✅ Web サービス / SaaS
• ✅ 継続的デリバリー（1 日 1 回以上デプロイ）
• ✅ 小〜中規模チーム（2-50 名）
• ✅ クラウドネイティブ開発

向いていないプロジェクト

• ❌ 複数バージョンの並行サポートが必要
• ❌ リリースサイクルが長い（月 1 回以下）
• ❌ 厳格な変更管理が求められる業界

3. トランクベース開発

最もシンプルなアプローチです。

trunk（main）
  │
  ├─→ 短いブランチ（1-2 日）
  │     │
  │     └─→ 即マージ
  │
  └─→ 機能フラグで制御
        ↓
    本番はフラグで ON/OFF

基本原則

1. ブランチ寿命は 1-2 日以内
2. 1 ブランチ 1 コミット
3. 機能はフラグで制御
4. 継続的インテグレーション

機能フラグの例

// 機能フラグによる制御
if (featureFlags.isEnabled('new-checkout')) {
  // 新しいチェックアウトフロー
  return <NewCheckout />;
} else {
  // 従来のチェックアウトフロー
  return <LegacyCheckout />;
}

特徴

向いているプロジェクト

• ✅ 継続的デプロイメント（1 日数回）
• ✅ 成熟した DevOps 文化
• ✅ 自動化テストが充実
• ✅ アジャイル開発チーム

向いていないプロジェクト

• ❌ 手動テスト中心
• ❌ 変更管理が厳格
• ❌ 長期的な機能開発（数週間）

ブランチ戦略の選択ガイド

チーム規模で選ぶ

リリース頻度で選ぶ

業界・規制で選ぶ

実装パターン別ベストプラクティス

feature ブランチの開発フロー

# 1. 最新の状態を取得
git checkout main
git pull origin main

# 2. 機能ブランチを作成
git checkout -b feature/user-authentication

# 3. 開発（こまめにコミット）
git add .
git commit -m "feat: add login form component"

# 4. 上流と同期（競合回避）
git fetch origin
git rebase origin/main

# 5. プルリクエスト作成
git push -u origin feature/user-authentication

コミットメッセージの規約

【推奨フォーマット】
<type>(<scope>): <subject>

【type の例】
feat: 新機能
fix: バグ修正
docs: ドキュメント
style: コードフォーマット（機能変更なし）
refactor: リファクタリング
test: テスト追加
chore: ビルド・設定

【良い例】
feat(auth): add password reset functionality
fix(api): resolve null pointer exception in user service
docs(readme): update installation instructions

【悪い例】
update code
fixed bug
minor changes

マージ戦略の比較

1. マージコミット（Merge Commit）

git merge --no-ff feature-branch

*   マージコミット
|\
| * feature コミット 1
| * feature コミット 2
|/
* main コミット

メリット: ブランチの歴史が保存される デメリット: ヒストリが複雑に

2. スクウォッシュマージ（Squash and Merge）

git merge --squash feature-branch

* スクウォーズされた 1 コミット
* main コミット

メリット: ヒストリがシンプル デメリット: 個々のコミット履歴が失われる

3. リベースマージ（Rebase and Merge）

git rebase main
git checkout main
git merge feature-branch

* feature コミット 2（リベース後）
* feature コミット 1（リベース後）
* main コミット

メリット: 直線的なヒストリ デメリット: 共有ブランチでは危険

保護ブランチの設定（GitHub）

main ブランチの保護設定

✅ 必須設定
・Require a pull request before merging
  - Require approvals: 1 人以上
  - Dismiss stale reviews: ON

・Require status checks to pass before merging
  - CI テスト：必須
  - ビルド：必須

・Require branches to be up to date before merging
  - ON

✅ 推奨設定
・Include administrators
  - 管理者も制限（例外なし）

・Require signed commits
  - コミットの署名必須

ブランチ保護ルールの例（.github/branch-protection.yml）

# GitHub Actions で設定
name: Branch Protection

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm run build

よくある問題と解決策

問題 1: マージ競合が頻発する

原因: ブランチの寿命が長い、同期不足

解決策:

# 定期的に main を取り込む
git checkout feature-branch
git fetch origin
git rebase origin/main  # または git merge origin/main

問題 2: レビューがボトルネック

解決策:

• 1 PR を小さく（200-400 行以下）
• ドラフト PR を活用（早期フィードバック）
• CODEOWNERS で自動レビューアサイン

問題 3: リリースが不安定

解決策:

• release ブランチで最終テスト
• 本番デプロイは承認フロー
• 機能フラグでロールバック可能に

問題 4: 長期ブランチの統合地獄

解決策:

• 機能フラグで未完機能をマージ
• ブランチは最大 1-2 週間
• 統合テストを自動化

チームへの導入ガイド

ステップ 1: 現状分析

• 現在のワークフローを可視化
• ボトルネックの特定
• チームの不満・要望をヒアリング

ステップ 2: 戦略選択

• 本記事の選択ガイドを参照
• チーム規模・リリース頻度・文化を考慮
• 完璧を目指さない（80% ルール）

ステップ 3: 文档化

# ブランチ戦略

## 基本方針
- GitHub Flow を採用
- main は常にデプロイ可能

## ブランチ命名規則
- feature/xxx
- fix/xxx
- hotfix/xxx

## マージルール
- PR レビュー必須（1 名以上）
- CI グリーン必須

ステップ 4: ツール設定

• ブランチ保護ルールの設定
• CI/CD パイプラインの構築
• テンプレート（PR、イシュー）の作成

ステップ 5: 教育・トレーニング

• チームキックオフ
• ハンズオンセッション
• 最初の 1-2 週間はペアでフォロー

まとめ

ブランチ戦略の選択基準：

1. チーム規模——小規模ならシンプル、大規模なら体系化
2. リリース頻度——頻繁なら GitHub Flow/トランクベース
3. 業界規制——厳格なら GitFlow
4. 文化——アジャイル重視ならトランクベース

「完璧な戦略はない。チームに合った戦略を選べ」

重要なのは：

• チーム全員が理解・遵守できること
• 継続的に改善できること
• ツールより文化を重視すること

参考資料

• GitHub Flow
• GitFlow
• Trunk Based Development
• Atlassian Git Tutorial