ブランチ戦略の基礎

ブランチ戦略は、チーム開発において重要な役割を果たします。適切なブランチ戦略により、効率的で安全な開発が可能になります。

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

ブランチ戦略なしの問題

問題のある状況:

開発者A: 「mainブランチに直接コミットしてしまった...」
開発者B: 「どのブランチで作業すればいいの？」
開発者C: 「リリースはどうやって管理するの？」

// 問題点:
// - ブランチの使い方が統一されていない
// - 本番環境への影響が大きい
// - リリース管理が困難
// - チーム間の混乱

影響:

本番環境への影響
リリース管理の困難
チーム間の混乱
開発効率の低下

ブランチ戦略による解決

改善された状況:

適切なブランチ戦略:
- ブランチの使い方が統一される
- 本番環境が保護される
- リリース管理が容易になる
- チーム間の協力が向上する

メリット:

本番環境の保護
リリース管理の容易化
チーム間の協力向上
開発効率の向上

主要なブランチ戦略

1. Git Flow

定義: Git Flowは、Vincent Driessenが提唱したブランチ戦略です。複数のブランチタイプを使用して、開発、リリース、ホットフィックスを管理します。

ブランチ構成:

main (本番環境)
  └─ develop (開発環境)
      ├─ feature/* (機能開発)
      ├─ release/* (リリース準備)
      └─ hotfix/* (緊急修正)

実践例:

# 1. 初期設定
git checkout -b develop main
git push -u origin develop

# 2. 機能開発
git checkout -b feature/user-auth develop
# 開発作業...
git add .
git commit -m "ユーザー認証機能を実装"
git push -u origin feature/user-auth

# 3. developブランチにマージ
git checkout develop
git merge --no-ff feature/user-auth
git push origin develop

# 4. リリース準備
git checkout -b release/v1.0.0 develop
# バグ修正など...
git add .
git commit -m "リリース前のバグ修正"
git push -u origin release/v1.0.0

# 5. mainブランチにマージ
git checkout main
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "リリース v1.0.0"
git push origin main --tags

# 6. developブランチにもマージ
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop

# 7. リリースブランチを削除
git branch -d release/v1.0.0
git push origin --delete release/v1.0.0

# 8. ホットフィックス（緊急修正）
git checkout -b hotfix/critical-bug main
# 緊急修正...
git add .
git commit -m "緊急バグ修正"
git push -u origin hotfix/critical-bug

# 9. mainブランチにマージ
git checkout main
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "ホットフィックス v1.0.1"
git push origin main --tags

# 10. developブランチにもマージ
git checkout develop
git merge --no-ff hotfix/critical-bug
git push origin develop

# 11. ホットフィックスブランチを削除
git branch -d hotfix/critical-bug
git push origin --delete hotfix/critical-bug

メリット:

本番環境が保護される
リリース管理が明確
緊急修正が容易

デメリット:

複雑
小規模プロジェクトには過剰

2. GitHub Flow

定義: GitHub Flowは、GitHubが推奨するシンプルなブランチ戦略です。mainブランチとfeatureブランチのみを使用します。

ブランチ構成:

main (本番環境)
  └─ feature/* (機能開発)

実践例:

# 1. featureブランチを作成
git checkout -b feature/user-profile main
git push -u origin feature/user-profile

# 2. 開発作業
git add .
git commit -m "ユーザープロフィール機能を実装"
git push origin feature/user-profile

# 3. プルリクエストを作成（GitHubのWebインターフェース）

# 4. レビューと承認

# 5. mainブランチにマージ（GitHubのWebインターフェース）

# 6. mainブランチを更新
git checkout main
git pull origin main

# 7. featureブランチを削除
git branch -d feature/user-profile
git push origin --delete feature/user-profile

メリット:

シンプル
迅速なデプロイ
小規模プロジェクトに適している

デメリット:

リリース管理が困難
本番環境への影響が大きい可能性

3. GitLab Flow

定義: GitLab Flowは、GitLabが推奨するブランチ戦略です。環境ごとのブランチとupstream firstの原則を使用します。

ブランチ構成:

production (本番環境)
  └─ pre-production (ステージング環境)
      └─ main (開発環境)
          └─ feature/* (機能開発)

実践例:

# 1. featureブランチで開発
git checkout -b feature/new-feature main
# 開発作業...
git push -u origin feature/new-feature

# 2. mainブランチにマージ（プルリクエスト経由）

# 3. pre-productionブランチにマージ（ステージング環境）
git checkout pre-production
git merge main
git push origin pre-production

# 4. productionブランチにマージ（本番環境）
git checkout production
git merge pre-production
git push origin production

メリット:

環境ごとの管理が明確
デプロイの制御が容易

デメリット:

ブランチが多くなる
マージが複雑になる可能性

4. Trunk-based Development

定義: Trunk-based Developmentは、mainブランチ（trunk）を中心としたブランチ戦略です。短命なブランチのみを使用します。

ブランチ構成:

main (trunk)
  └─ feature/* (短命なブランチ、1-2日でマージ)

実践例:

# 1. featureブランチを作成
git checkout -b feature/small-change main

# 2. 迅速に開発（1-2日以内）
git add .
git commit -m "小さな変更"
git push -u origin feature/small-change

# 3. すぐにmainブランチにマージ
git checkout main
git merge feature/small-change
git push origin main

# 4. featureブランチを削除
git branch -d feature/small-change
git push origin --delete feature/small-change

メリット:

シンプル
マージコンフリクトが少ない
迅速な開発

デメリット:

大規模な機能開発には不向き
コードレビューが必須

ブランチ戦略の選択指針

プロジェクトの規模

小規模プロジェクト（1-5人）:

推奨: GitHub Flow、Trunk-based Development
理由: シンプルで迅速

中規模プロジェクト（5-20人）:

推奨: Git Flow、GitLab Flow
理由: リリース管理が明確

大規模プロジェクト（20人以上）:

推奨: Git Flow、GitLab Flow
理由: 複雑な管理が必要

リリース頻度

頻繁なリリース（週次以上）:

推奨: GitHub Flow、Trunk-based Development
理由: 迅速なデプロイが可能

定期的なリリース（月次）:

推奨: Git Flow
理由: リリース管理が明確

不定期なリリース:

推奨: Git Flow、GitLab Flow
理由: リリース準備が容易

まとめ

ブランチ戦略の基礎のポイント：

Git Flow: 複数のブランチタイプ、リリース管理が明確
GitHub Flow: シンプル、迅速なデプロイ
GitLab Flow: 環境ごとの管理、デプロイの制御
Trunk-based Development: 短命なブランチ、迅速な開発
選択指針: プロジェクトの規模、リリース頻度を考慮

適切なブランチ戦略を選択することで、効率的で安全な開発ができます。