ブランチ戦略の選び方

チーム開発でブランチの運用ルールが統一されていないと、さまざまな問題が発生します。

ブランチ名がバラバラで何の作業かわからない、マージのタイミングが人によって異なりコンフリクトが頻発する、リリースに含めるべき変更が漏れる――こうした混乱を防ぐために、事前にブランチ戦略を決めておくことが重要です。

ブランチ戦略で決めるべきポイントは主に3つです。

1. ブランチの命名規則 ― feature/、hotfix/ などのプレフィックスを統一する
2. マージのタイミング ― レビュー完了後にマージする、CI が通ってからマージするなどのルール
3. リリースの方法 ― main ブランチを直接デプロイするのか、リリースブランチを切るのか

GitHub Flow はシンプルさが特徴のブランチ戦略です。

使うブランチは main と feature ブランチの2種類だけ。

小規模〜中規模のチームや、継続的にデプロイするプロジェクトに最適です。

基本ルール

1. main ブランチは常にデプロイ可能な状態を保つ
2. 新しい作業は必ず main から feature ブランチを作成して行う
3. feature ブランチで作業が完了したら Pull Request を作成する
4. レビューを受けて承認されたら main にマージする
5. main にマージされたら即座にデプロイする

	内容
メリット	覚えることが少なくシンプル。CI/CD と相性が良い
デメリット	リリースのバージョン管理が難しい。複数バージョンの同時サポートには不向き

# 1. feature ブランチを作成
git switch -c feature/user-auth

# 2. 作業してコミット
git add .
git commit -m "Add user authentication"

# 3. リモートに push
git push -u origin feature/user-auth

# 4. GitHub で Pull Request を作成してレビューを受ける

# 5. レビュー後に main へマージ（GitHub 上で実行）

Git Flow は5種類のブランチを使う、より構造化されたブランチ戦略です。

リリースサイクルが明確なプロジェクトや、複数バージョンを同時にサポートする必要がある大規模プロジェクトに適しています。

ブランチの種類

ブランチ	役割
main	リリース済みのコードを保持。タグでバージョンを管理
develop	次のリリースに向けた開発の統合ブランチ
feature/	新機能の開発用。develop から分岐し、develop にマージ
release/	リリース準備用。develop から分岐し、main にマージ後 main → develop に反映
hotfix/	緊急修正用。main から分岐し、main にマージ後 main → develop に反映

	内容
メリット	リリース管理が明確。複数バージョンのサポートが容易
デメリット	ブランチが多く複雑。小規模プロジェクトではオーバーヘッドが大きい

各フェーズの詳しい流れは Git Flow を時系列で理解する を参照してください。

# feature ブランチ（develop から分岐）
git switch develop
git switch -c feature/payment
# ... 作業後 ...
git switch develop
git merge feature/payment

# release ブランチ（develop から分岐）
git switch develop
git switch -c release/1.2.0
# ... リリース準備（バージョン番号修正等）...
git switch main
git merge release/1.2.0
git tag v1.2.0
git switch develop
git merge main          # リリース内容を develop に反映

# hotfix ブランチ（main から分岐）
git switch main
git switch -c hotfix/security-patch
# ... 修正後 ...
git switch main
git merge hotfix/security-patch
git tag v1.2.1
git switch develop
git merge main          # hotfix + タグを develop に反映

トランクベース開発は、main ブランチ（トランク）に直接コミットするか、非常に短命なブランチ（1〜2日以内にマージ）を使う手法です。

CI/CD パイプラインが十分に整備されていることが前提となります。

基本ルール

1. main に直接コミット、または短命ブランチ（1〜2日）でマージ
2. 長期間のブランチを作らない
3. 未完成の機能はフィーチャーフラグで制御する
4. 自動テストと CI/CD が必須

フィーチャーフラグとの組み合わせ

未完成の機能をコードに含めつつ、フラグで有効・無効を切り替えることで、ブランチを長期間維持する必要がなくなります。

リリース時にフラグを有効にするだけで機能を公開できます。

	内容
メリット	マージコンフリクトが最小限。コードの統合が常に行われる。デプロイ頻度が高い
デメリット	CI/CD の整備が前提。自動テストのカバレッジが低いと品質リスクが高い

迷ったらまず GitHub Flow から始めましょう。

シンプルで導入しやすく、多くのプロジェクトで十分に機能します。

GitHub Flow が向いている場合:

• チームが小〜中規模
• Web アプリケーションなど継続的にデプロイするプロジェクト
• リリースバージョンの管理が不要

Git Flow を検討すべき場合:

• モバイルアプリなどリリースサイクルが明確
• 複数バージョンを同時にサポートする必要がある
• QA チームによるリリース前テストが必要

トランクベース開発を検討すべき場合:

• CI/CD パイプラインが成熟している
• 自動テストのカバレッジが十分
• 1日に複数回デプロイする体制がある

最も大切なのは、チーム全員がルールを理解し、一貫して運用することです。

途中で戦略を変更することもできるので、まずは始めてみて、チームの成長に合わせて見直していきましょう。