Git Flowとは何か、ブランチングモデルとプロジェクトでの活用

Git Flowとは何か？

Git Flowは、開発、リリース、修正を管理するためのブランチとマージルールの厳密な構造を定義するGitブランチングモデルです。Vincent Driessenは2010年1月に「A successful Git branching model」を公開し、それ以来Git Flowは企業Java・.NET開発での事実上の標準となりました。主なアイデアは、コードを5つのタイプのブランチに分け、それぞれに異なる安定度レベルを持たせることです。

Atlassian Git Tutorials, 2024によると、Git Flowは2つの永続ブランチ（main、旧master、develop）に基づいています。その他のブランチはすべて一時的です：feature、release、hotfix。各ブランチタイプには明確に定義されたライフサイクルとマージルールがあります。モバイル開発では、Git Flowは定期的なリリースサイクル（2–4週間）および複数バージョンサポートがあるプロジェクトで使用されます。

Git Flowは、統合のための独立したdevelopブランチが必要な点で、簡素なモデル（GitHub Flow）とは異なります。これによりマージプロセスに1ステップ追加されますが、完了していないフィーチャーをリリース済コードからアイソレートできます。

Vincent DriessenとGit Flowの歴史

2010年、Vincent Driessenは「A successful Git branching model」を公開し、これはGit歴史で最も引用された記事の1つとなりました。このモデルは、固定リリースと並行バージョンサポートを持つプロジェクトのために作られました。2020年、DriessenはGit Flowが現代のCI/CD実践には古いと認めましたが、このモデルは長いリリースサイクルと古いバージョンサポートが必要なプロジェクトにとって依然として重要です。

# Git Flowを初期化
git flow init

# フィーチャーブランチを作成
git flow feature start "add-auth"

# フィーチャーブランチを完了（developにマージ）
git flow feature finish "add-auth"

# リリースを作成
git flow release start "1.2.0"
git flow release finish "1.2.0"

Mainブランチ: リリースコードとタグ付け

Main（旧master）は、デプロイ済みのリリースコードのみを含む主ブランチです。mainへの各コミットは、セマンティックバージョニング形式でタグ付けされた特定の製品バージョンに対応する必要があります。例えばv1.0.0、v1.1.0などです。mainで直接開発することはできず、変更はreleaseブランチまたはhotfixブランチを通じてのみもたらされます。

semver.org, 2024によると、mainのタグはMAJOR.MINOR.PATCH形式を使用します。MAJORは互換性のないAPI変更に対して増加され、MINORは互換性を維持した機能追加に対して、PATCHはバグ修正に対して増加されます。Git Flowでは、各リリースの完了時にバージョンタグ付きのコミットが自動的にmainに作成されます。

Mainブランチは、プロダクションにデプロイされる唯一のブランチです。モバイルプロジェクトでは、mainへのプッシュでApp BundleやIPAのビルドパイプラインが開始され、Google Play / App Storeへ公開されます。GitLab CI/CDの設定では、mainはforce-pushと削除から保護されています。

セマンティックバージョニングとタグ

mainへの各コミットには、SemVer形式（vMAJOR.MINOR.PATCH）のタグが付きます。MAJOR—互換性のないAPI変更、MINOR—互換性を維持した新機能、PATCH—バグ修正。例えばv2.1.0は、バグ修正のない新機能付きの2番目のメジャーリリースを意味します。Git Flowでは、git flow release finishコマンドでreleaseまたはhotfixを完了すると、タグが自動的に作成されます。

Developブランチ: 開発の統合ライン

DevelopはGit Flowで2番目の永続ブランチで、完了したすべてのフィーチャーを統合するために設計されています。開発者は、コードレビューとCI/CDチェックを通した後にfeatureブランチをdevelopにマージします。Developには、現在のスプリントで実装されたすべての機能を含む最新の安定コードが含まれています。

DataSift Git Flow Guide, 2024によると、developは進行中の統合によって一時的に不安定になることがあります。問題を防ぐため、チームはコンティニュアスインテグレーション（CI）を実践しています：各フィーチャーはdevelopにマージされる前に完全なテストスイートを経なければなりません。CIが失敗した場合、開発者は次のマージの前にコードを修正します。Developは常に現在のmainバージョンに結びついており、リリース直後にマージを通じてdevelopがmainに同期されます。

Featureブランチ: 新しい機能の開発

フィーチャーブランチは、個別のフィーチャー、バグ修正、または実験のための一時的なブランチです。各フィーチャーブランチはdevelopから作成され、完了後にdevelopに戻されます。フィーチャーブランチの名前には、一般的にタスク番号や簡単な説明が含まれます：feature/APP-123-add-oauth、feature/redesign-profileなど。Git Flowでは、フィーチャーブランチは無限期間存在できます。

Pro Git Book, 2024によると、フィーチャーブランチは独立した開発環境です：あるブランチの変更は、マージされるまで他のブランチに影響を与えません。モバイルプロジェクトでは、完了時の大きな競合を避けるため、featureブランチはrebaseまたはmergeを使ってdevelopに同期されます。MRを作成する前に、フィーチャーブランチをdevelopにリベースすることが推奨されます。

# マニュアルフィーチャーブランチ作成（git flowなし）
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# CLIを使ってGitLabでMRを作成
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Releaseブランチ: リリースの準備

Releaseブランチは、リリースの準備のためにdevelopから作成される一時的なブランチです。developに新しいバージョンに十分な機能が集まったら、チームはrelease/X.Y.Zブランチを作成します（例：release/2.1.0）。このブランチでは、バージョンアップ、ローカライゼーションの更新、最終テスト、クリティカルなバグ修正といった最終変更のみが行われます。

Atlassian Git Tutorials, 2024によると、releaseブランチは以下の主な問題を解決します：最終変更を並行開発からアイソレートすること。リリースの準備中に、次のリリースのための新機能がdevelopにマージされ続けます。完了後、releaseブランチはmain（タグ付き）とdevelop（バージョンアップを同期するため）にマージされます。

Hotfixブランチ: プロダクションでの緊急修正

Hotfixブランチは、プロダクションのクリティカルなバグを緊急修正するための一時的なブランチです。Git Flowでdevelopではなくmainから作成される唯一のブランチタイプです。名前形式: hotfix/X.Y.Z+1（例：hotfix/2.1.1）。完了後、hotfixブランチは同時にmain（新しいパッチリリースとして）とdevelop（修正が将来のリリースで失われないように）にマージされます。

DataSift Git Flow Guide, 2024によると、hotfixブランチはできるだけ短くすべきです—修正とテストのみです。hotfixに新機能やリファクタリングを含めてはなりません。モバイル開発では、hotfixはクリティカルなクラッシュ（クラッシュ率 > 0.1%）、セキュリティ負具性、またはApp Storeのブロッキングバグの修正に使用されます。

モバイル開発におけるGit Flowの利点と缺点

Git Flowは、大きなチームや定期的なリリースがあるプロジェクトで特に役立つ明確な構造を提供します。利点：フィーチャーブランチでの完了していない機能のアイソレーション、開発をブロックせずにリリースを準備できること、hotfixによる複数バージョンサポート。缺点：初心者には複雑、定期的なフィーチャーブランチのリベースが必要、長期生存ブランチでの競合。

Martin Fowler, 2024によると、Git Flowの主な缺点は長期生存のフィーチャーブランチです。2週間以上、developと同期せずにフィーチャーを開発すると、マージ競合が大きくなります。モバイルプロジェクトでは、毎日リベースを使ってフィーチャーブランチをdevelopに同期することが推奨されます。

Git Flowは、コンティニュアスデプロイメント（各コミットをmainへ→プロダクション）のプロジェクトには推奨されません。そうしたプロジェクトでは、GitHub FlowやTrunk-Based Developmentのほうが簡素で高速なモデルを提供します。しかし、リリースサイクルがあり、古いバージョンをサポートする必要があるプロジェクトでは、Git Flowが最適な選択です。

Git Flowがチームに有害な場合

Git Flowは次の3つの場合に問題となります：5人未満のチーム（不要な複雑さ）、コンティニュアスデプロイメント（デリバリーの遅延）、リベースの紀律不足（長期生存のフィーチャーブランチがマージ競合を生み出す）。チームがブランチのマージと競合解決に20%以上の時間を費やしている場合—Git Flowはそのチームには不適切です。

Git Flowの代替: GitHub FlowとTrunk-Based Development

Git Flowの代替は、CI/CDを実践するチームに簡素なプロセスを提供します。GitHub Flowは、一つの永続ブランチ（main）とfeatureブランチのみを使用します。各フィーチャーはmainから作成され、レビューとCIの後にmainに戻され、即座にデプロイされます。GitHub Flowはより簡素ですが、完了していないフィーチャーのアイソレーションや並行リリース準備をサポートしません。

GitHub Docs, 2024によると、Trunk-Based Development (TBD)はさらに進んでいます：すべての開発者が1つのブランチ（trunk）で動作し、1–2日の短期フィーチャーブランチを使用します。Feature togglesは未完了のコードの可視性を制御します。TBDには、高いCI/CDの紀律とテスト自動化が必要です。

• GitHub Flow — 1つのmain + featureブランチ、CI/CDと小チームに最適
• GitLab Flow — Git Flowを環境ブランチ（staging, production）で拡張
• Trunk-Based Development — 1ブランチ + feature toggles、最大CI/CD、最小マージ
• One Flow — developブランチなしの簡素化Git Flow、main + feature + releaseのみ