Gitのブランチ戦略｜Git Flow・GitHub Flowの違いと選び方

Gitのブランチ戦略とは、チームで「どんなブランチを作り、どのように統合し、どこからリリースするか」を決めたルールです。代表的なものに、Git Flow・GitHub Flow・GitLab Flow・トランクベース開発の4つがあります。

どれが正解というものではなく、リリースの頻度と、同時に管理するバージョンの数で向き不向きが決まります。この記事では、4つの戦略の違いを整理したうえで、チームに合った戦略の選び方、ブランチの保護ルールや命名規則、フィーチャーフラグなど、どの戦略でも役立つ運用の工夫を解説します。

4つのブランチ戦略の比較

Git Flow

main     ●──────────────●──────────●   （リリースされたバージョン）
          \            / \        /
release    \      ●───●   \      /
            \    /         \    /
develop  ●───●──●───●───●───●──●   （開発の最新）
              \     /
feature        ●───●                 （機能ごとのブランチ）

向いている場面：スマホアプリのようにストアの審査があるもの、パッケージソフト、複数のバージョンを並行して保守する製品など、リリースに準備期間が必要な開発です。

注意点：ブランチの種類が多く、統合の手順も複雑です。Webサービスのように頻繁にリリースする開発では、手間が大きすぎることがあります。Git Flowを提唱した作者自身も、継続的にデリバリーするWebアプリには、よりシンプルな方式を勧めています。

GitHub Flow

main     ●────●────●────●────●   （常にリリースできる状態）
          \       /  \      /
feature    ●──●──●    ●──●──●     （プルリクエストでレビューして統合）

1. mainからブランチを作る
2. 作業してコミットし、pushする
3. プルリクエストを作り、レビューを受ける
4. CI（自動テスト）が通り、承認されたらmainに統合する
5. mainに統合したら、すぐにデプロイする

ルールは「mainは常にリリースできる状態に保つ」の1つだけ、と言えるほどシンプルです。

向いている場面：Webサービスや社内ツールなど、いつでもデプロイでき、1つのバージョンだけを運用する開発です。小規模なチームや、個人開発にも向いています。

注意点：mainに統合したものがすぐにリリースされるため、自動テストとレビューの質が前提になります。検証環境で確認してからリリースしたい場合は、次のGitLab Flowの考え方を組み合わせます。

GitLab Flow

GitHub Flowに、環境（検証・本番）ごとのブランチを加えた方式です。

main        ●───●───●───●     （開発の最新・開発環境）
                 \       \
staging           ●───────●   （検証環境）
                   \       \
production          ●───────● （本番環境）

mainに統合したものを、検証環境 → 本番環境の順に、ブランチを進めてリリースします。

向いている場面：業務システムのように、お客様の検証やリリースの承認の手順がある開発です。GitHub Flowの手軽さを保ちながら、段階的なリリースができます。

トランクベース開発

全員が、main（trunk）に、少なくとも1日1回以上、小さな単位で統合する方式です。ブランチを作る場合も、数時間〜1日程度のごく短命なものにします。

未完成の機能は、フィーチャーフラグで隠したままmainに統合します。これにより、長期間のブランチが生まれず、大きなコンフリクトや、統合の直前の混乱を避けられます。

向いている場面：頻繁にデプロイする大規模な開発です。ただし、充実した自動テスト、フィーチャーフラグの仕組み、小さく分けて統合する習慣が前提になるため、導入の難易度は高めです。

チームに合った戦略の選び方

迷ったら、GitHub Flowから始めるのがおすすめです。最もシンプルで、必要になったときに、releaseブランチや環境ブランチを追加していけます。最初から複雑な戦略を選ぶと、ルールを守ること自体が負担になりがちです。

どの戦略でも役立つ運用のルール

ブランチの命名規則

種類／チケット番号-内容の形にすると、ブランチの一覧から、目的と関連するチケットがすぐにわかります。コミットメッセージのプレフィックス（feat・fixなど）と揃えると、さらに統一感が出ます。

ブランチの保護ルール

GitHubやGitLabでは、mainなど重要なブランチに保護ルールを設定できます。

ルールを人の注意だけで守るのではなく、仕組みで守るのがポイントです。

ブランチは短命に保つ

どの戦略でも、機能ブランチが長く生きるほど、mainとの差が開き、統合時のコンフリクトとレビューの負担が大きくなります。

• 1つのブランチは、数日以内に統合できる大きさに分ける
• 大きな機能は、「DBの変更」「API」「画面」のように段階に分けて統合する
• 長くかかる場合は、mainの変更をこまめに取り込む

フィーチャーフラグ

未完成の機能や、段階的に公開したい機能を、設定で表示・非表示を切り替えられるようにする仕組みです。

if (featureFlags.isEnabled("new-checkout")) {
    showNewCheckout();
} else {
    showOldCheckout();
}

• 未完成の機能を、隠したままmainに統合できる
• 一部の利用者だけに先に公開し、問題がなければ全体に広げられる
• 問題が起きたら、デプロイし直さずにすぐに元に戻せる

使い終わったフラグは、コードから削除することを忘れないようにします。残し続けると、条件分岐が増え、コードが読みにくくなります。

緊急の修正（ホットフィックス）

緊急時の手順を、平常時に決めておくことが大切です。慌てているときほど、手順を省いて新たな問題を起こしやすくなります。

AIと一緒に開発するときの運用のコツ

AIのコーディング支援を使うと、短時間で大量のコードが生成されるため、ブランチの運用にも工夫が必要です。

• 1つの作業を、1つの小さなブランチ・プルリクエストに：AIにまとめて大きな変更をさせると、レビューが追いつかない
• AIの作業用のブランチを分ける：試行錯誤の結果は、整理してから統合する
• 保護ルールとCIを必ず設定する：AIが生成したコードも、人のコードと同じくレビューとテストを通す
• 複数のAIエージェントが並行して作業する場合は、ブランチ（またはgitの作業ディレクトリ）を分け、同じファイルを同時に変更しないように作業を割り振る

よくある質問

Q. developブランチは必要ですか？ A. Git Flowでは必要ですが、GitHub Flowでは使いません。頻繁にリリースするWebサービスでは、developとmainの二重管理が負担になることが多く、GitHub Flowの方がシンプルです。

Q. 小規模なチームや個人開発では、どれを使えばいいですか？ A. GitHub Flowがおすすめです。個人開発でも、mainを常に動く状態に保ち、作業はブランチで行う習慣をつけておくと、失敗したときに簡単に元に戻せます。

Q. プルリクエストの統合方法（マージ・スカッシュ・リベース）はどれがいいですか？ A. チームで1つに統一することが大切です。履歴を1プルリクエスト1コミットに整理したいならスカッシュ、コミットを丁寧に分けて残したいならリベースやマージコミットが向いています。詳しくは、mergeとrebaseの違いの記事で解説しています。

Q. ブランチ戦略を途中で変えてもいいですか？ A. 変えて構いません。チームの人数やリリースの方法が変われば、合う戦略も変わります。変更するときは、移行のタイミングと新しいルールをチーム全員で共有します。

まとめ

• ブランチ戦略は、ブランチの作り方・統合の仕方・リリースの仕方のルール
• Git Flow：リリースに準備期間がある・複数バージョンを保守する製品向け
• GitHub Flow：mainを常にリリース可能に保つ、シンプルな方式。迷ったらここから
• GitLab Flow：環境ごとのブランチで、検証を経て段階的にリリース
• トランクベース開発：小さく頻繁に統合。自動テストとフィーチャーフラグが前提
• どの戦略でも、命名規則・保護ルール・短命なブランチが効く
• AIと開発するときは、小さなプルリクエストとCIで品質を保つ

株式会社RJCでは、Gitのようなチーム開発の基本を、実際に手を動かしながら仲間と教え合っています。こうした知識を共有しながら、一緒に成長を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。