ブランチ戦略の設計

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

チーム開発でブランチを無秩序に作成すると、次のような問題が発生します：

🌳 ブランチの迷宮

• 「どのブランチが何の作業用か分からない」
• 「古いブランチが大量に残っている」
• 「マージすべきブランチを間違える」

🔥 環境の混乱

• 「開発中の機能が本番環境に混入」
• 「テスト環境と本番環境の差異が不明」
• 「緊急修正がどこに適用されているか不明」

ブランチ戦略の基本概念

ブランチ戦略は、ブランチの種類、命名規則、ライフサイクルを定義することで、これらの問題を解決します。

主要なブランチタイプ

1. 長期ブランチ（Long-lived branches）

プロジェクトの全期間を通じて存在するブランチです。

main/master（本番ブランチ）

• 役割: 本番環境の状態を反映
• 特徴:
  • 常にデプロイ可能な状態を維持
  • 直接コミットは原則禁止
  • タグでリリースバージョンを管理

# mainブランチの状態確認
git log main --oneline -10

# リリースタグの確認
git tag -l "v*"

develop（開発ブランチ）

• 役割: 次期リリースの統合ブランチ
• 特徴:
  • 各featureブランチの統合先
  • CI/CDでテスト環境にデプロイ
  • 定期的にmainへマージ

2. 短期ブランチ（Short-lived branches）

特定の目的のために作成され、目的達成後に削除されるブランチです。

feature（機能ブランチ）

• 役割: 新機能や改善の実装
• 命名規則: feature/機能名 または feature/issue番号-機能名
• ライフサイクル:
  1. developから分岐
  2. 機能を実装
  3. developへマージ
  4. ブランチを削除

# featureブランチの作成例
git checkout develop
git checkout -b feature/user-profile

# 作業後のマージ
git checkout develop
git merge --no-ff feature/user-profile
git branch -d feature/user-profile

release（リリースブランチ）

• 役割: リリース準備とバグ修正
• 命名規則: release/バージョン番号
• ライフサイクル:
  1. developから分岐
  2. バージョン番号更新、最終調整
  3. mainとdevelopへマージ
  4. mainにタグ付け
  5. ブランチを削除

# releaseブランチの作成
git checkout -b release/v1.2.0 develop

# リリース完了後
git checkout main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git checkout develop
git merge --no-ff release/v1.2.0

hotfix（緊急修正ブランチ）

• 役割: 本番環境の緊急バグ修正
• 命名規則: hotfix/問題の説明
• ライフサイクル:
  1. mainから分岐
  2. バグを修正
  3. mainとdevelopへマージ
  4. mainにタグ付け
  5. ブランチを削除

ブランチ命名規則

推奨される命名パターン

# 機能追加
feature/add-payment-method
feature/JIRA-123-user-authentication
feature/issue-456-dark-mode

# バグ修正
fix/login-validation-error
bugfix/JIRA-789-cart-calculation
hotfix/critical-security-patch

# リファクタリング・改善
refactor/optimize-database-queries
chore/update-dependencies
docs/api-documentation

# リリース
release/v2.1.0
release/2024-Q1

命名のベストプラクティス

1. 小文字とハイフンを使用

   • ❌ feature/UserProfile
   • ✅ feature/user-profile

2. 動詞から始める

   • ❌ feature/profile
   • ✅ feature/add-user-profile

3. 簡潔で説明的に

   • ❌ feature/stuff
   • ✅ feature/implement-oauth-login

ブランチ保護ルール

重要なブランチを保護するためのルール設定：

mainブランチの保護

• 直接プッシュを禁止
• マージ前にPull Requestを必須化
• レビュー承認を必須化
• CI/CDのテスト成功を必須化

developブランチの保護

• 直接プッシュを制限
• マージ前にテスト実行
• コードレビューを推奨

ブランチの整理

不要なブランチの削除

# マージ済みのローカルブランチを確認
git branch --merged

# マージ済みのブランチを削除
git branch -d feature/old-feature

# リモートブランチの削除
git push origin --delete feature/old-feature

# 削除されたリモートブランチの参照を削除
git remote prune origin

ブランチ一覧の確認

# ローカルブランチ一覧
git branch

# リモートブランチも含めた一覧
git branch -a

# 最終コミット日時付きで表示
git for-each-ref --sort=-committerdate refs/heads/ --format='%(committerdate:short) %(refname:short)'

実践演習

まとめ

効果的なブランチ戦略は、チーム開発の生産性と品質を大きく向上させます。プロジェクトの性質に応じて適切な戦略を選び、チーム全体で一貫性を保つことが重要です。

次のレッスンでは、これらのブランチ間での変更を統合する「Pull Request/Merge Request」について学びます。