#176 チーム特性から考える Git ブランチ戦略の選定

はじめに

チーム開発における「最適な Git ブランチ運用」は、チーム構成やリリース頻度、メンバーのスキルセットなどの組織的な条件によって大きく変わります。
しかし実際の現場では「なんとなく Git Flow を採用している」「以前からの運用をそのまま続けている」といった理由から、明確な根拠なくブランチ戦略が選ばれているケースも少なくありません。

私自身、継続的に開発・デプロイを繰り返す Web アプリの開発を行う中で、ブランチ運用について改めて考える場面がありました。
良い機会だと感じたので、備忘録も兼ねて整理した内容をいくつかの記事に分けてまとめていきたいと思います。

今回の記事では、次の2点を中心に整理していきます。

• 一般的に知られている Git ブランチ戦略の特徴をざっくり振り返り
• 自分たちのチームに最適な戦略を選ぶための観点の整理

Git の代表的なブランチ戦略とその特徴

Git を使った開発にはさまざまなブランチ運用（戦略）があり、それぞれ得意な領域が異なります。

ここでは、まずは代表的な4つの戦略を以下の観点で整理します。

• 安定ブランチ数：常に安定したブランチ（常に動作保証されたブランチ）がいくつあるか
• リリース頻度との相性：どの程度の頻度でのリリースに向いているか
• スキル要求度：操作や運用で求められる Git スキル
• CI/CD 文化の導入必要度：自動化やテストの整備がどれくらい必要か

さらにそれぞれの方法論、メリット／デメリット、どのようなチーム・プロジェクトが向いているのかについて確認していきます。

各戦略の観点整理

戦略	安定ブランチ数	リリース頻度との相性	スキル要求度	CI/CD 文化の導入必要度
Git Flow	複数 → main, develop, release など	中〜低 → 計画的・スケジュール型リリース向き	中〜高	中 → 自動化があると運用がスムーズ
GitHub Flow	少なめ → 主に main + 機能ブランチ	高 → 継続的デリバリ／デプロイ向き	低〜中	高 → マージとデプロイを直結させることが前提
GitLab Flow	中 → main＋環境ブランチなどが選択可能	幅広く対応可能 → 小規模から大規模まで柔軟に対応	中	高 → GitLab CI/CD と統合して使うことが前提
Trunk-Based Development	最小 → 基本は一本の幹で運用	非常に高 → 頻繁なマージ／リリース	中〜高	必須 → CI/CD が整備されていないと運用できない

各戦略の特徴：1. Git Flow

参考：Gitflow 分岐戦略

特徴

• feature、develop、release、hotfix など、複数の目的別ブランチを使って明確に構造を分ける
• 開発は feature → develop へマージ
• リリースが近づいたら release ブランチを切って安定化 → 本番（main）に統合
• 緊急修正は hotfix から main にマージ

メリット

• ブランチ構造が明快で、長期的・計画的なリリースに強い
• リリース前に安定化フェーズを設けられるので QA 管理がしやすい
• ブランチ間の責任範囲がはっきりしている

デメリット

• ブランチ数が増えるため、他の戦略と比べると運用コストが高くなりがち
• マージ作業や統合の手間が大きい
• 自動化・CI が整っていないと運用コストが高くなり、開発スピードが遅くなる

向いているチーム／プロジェクト

• リリースサイクルが明確（例：月1、四半期ごとのリリースなど）
• 複数バージョンを長期的に運用する（LTS など）
• ニーズ：QA チームがあるなど、検証フェーズをしっかり担保したい

各戦略の特徴：2. GitHub Flow

参考：GitHub フロー分岐戦略

特徴

• 短命な feature ブランチを作成 → 完了したら main にマージ、というシンプルな運用
• マージリクエスト（Pull Request）によるレビュープロセスを経て main に統合
• main にマージされたら即デプロイ、という運用が一般的

メリット

• 軽量でスピーディ。手順が少ないので新機能を素早くリリースできる
• チーム内でのコミュニケーションがよくできていれば、無駄が少ない
  • →チーム内のコミュニケーションが不足している場合、マージ前のレビューや調整が遅れ、競合やバグが増える可能性がある
• 小規模チームやスタートアップに適する

デメリット

• 厳密なリリース管理がないため、大規模プロジェクトでは不安定になることがある
  • →大規模チームでは複数の機能が同時進行しやすく、安定したリリースや品質の維持が難しくなることが懸念される
• マージ競合が頻発する可能性があり、解決にはスキルが必要
• 複数バージョンを並行して維持したり、長期保守する場合、安定ブランチが少ないため管理が難しい

向いているチーム／プロジェクト

• 継続的デプロイが可能な体制（CI/CD が整っている）である
• 開発者が Git にある程度慣れていて、レビューをきちんと運用できる
• ニーズ：リリースごとのフェーズを厳密に分けず、常に最新を出していきたい

各戦略の特徴：3. GitLab Flow

参考：GitLab Flowとは、GitLab Flow (フロー) と GitLab Duo (デュオ) を併用してワークフローを強化する

特徴

• Git Flow のような構造化ブランチモデルを簡略化し、Issue トラッキングと統合されたワークフロー
• main ブランチを軸に、本番用またはステージング用の環境ブランチ（例：production, staging）を作るパターンの運用が可能
• GitLab Duo などを使えば、レビュー環境・セキュリティチェックなどをワークフローに組み込める

メリット

• GitLab の CI/CD や Issue 管理との親和性が非常に高く、DevSecOps 的な運用が可能
• リリース前の安定ブランチを柔軟に定義できるので、安定性とスピードのバランスを取りやすい
• レビュー環境をブランチごとに作って確認できる

デメリット

• ブランチ設計の自由度が高いため、運用ルールを明確にしないと混乱しやすい
• GitLab 固有の機能に依存する部分が出てくる（CI/CD、MR パイプラインなど）
• スキルによっては、複雑な環境ブランチの運用が難しい

向いているチーム／プロジェクト

• GitLab をメインのリポジトリ／CI ツールとして使用している
• セキュリティやレビューを重視しつつ、継続的なデリバリ（CD）および小さな単位でのリリースを目指す
• ニーズ：本番・ステージング・開発環境を明確に分けたいが、構造を柔軟にしたい

各戦略の特徴：4. Trunk-Based Development（トランクベース：TBD）

参考：トランク分岐戦略

特徴・メソッド

• 開発者は基本的に単一の「幹（trunk / main）」ブランチに頻繁にマージ
• 小さな変更を短期間でマージし、自動テストを回しながらコードベースを常に「リリース可能な状態」に保つ
• 機能トグル（feature flag）を併用して、未完成の機能も本番ブランチに入れつつ、実際に有効化・無効化を制御することが多い
  • →AWS でも小さな変更を頻繁に促すベストプラクティスがある

メリット

• ブランチ数が非常に少ないため、運用がシンプル
• 継続的統合（CI）および継続的デリバリ（CD）を最大限に活かせる
• コンフリクトが早期に発見されるため、小さく解消しやすい

デメリット

• チームの成熟度や Git、CI スキルが低いと破綻しやすい
• 自動化が未整備だとリスクが高い（テスト、ビルド、レビューが追いつかない）
• 大きな機能を一括で安定させるのが難しい

向いているチーム／プロジェクト

• CI/CD がしっかり整備されていて、自動テストが高速に回せる体制である
• リリース頻度が高く、小さな変更を推進できる文化がある
• 高い開発成熟度を持ち、feature toggle を使った運用ができる
• ニーズ：高速なフィードバックサイクルで開発を回したい

どの戦略も一長一短がありますが、チームの特性や状況に応じて最適な戦略を選べる視点を持つことが重要です。

ブランチ戦略を考える際のポイント

ブランチ戦略は「Git の仕様」だけで決めるものではなく、「チームの状況（組織的条件）」と「実際の技術的な運用ルール」の両面から検討する必要があります。
ここを整理せずにルールだけ導入すると、すぐ破綻したり、現場で無言の例外運用が広がったりします。

この章では、ブランチ戦略を決める前に考えるべきポイントを、上位観点（組織的な条件）と下位観点（技術的な運用ルール）に分けて解説します。

上位観点：組織的な条件

まずは「どんなチームが運用するのか」という前提を整理していきましょう。
ここを無視してしまうと、綺麗なブランチ戦略を設計しても現場にフィットせず、形骸化する可能性があります。

この章では、以下4つの観点で組織的条件を整理します。

• チーム構成（人数・役割・レビュー文化）
• メンバーの Git スキル
• リリース頻度（デプロイ頻度）
• プロジェクトの種類

1. チーム構成（人数・役割・レビュー文化）

ブランチ戦略は、単に人数だけでなく「どのような役割構成のチームなのか」によっても大きく変わります。

人数による影響

規模	想定人数	特徴	相性の良い戦略
小規模	1〜5名	・コミュニケーションコストが低く、軽量な運用が可能 ・PR のレビューを1〜2名で回せるため高速	GitHub Flow / Trunk-Based のような少数ブランチ構成
中規模	5〜20名	・並行開発が増えるケースが多く、安定ブランチの扱いが重要 ・レビュー負荷の分散が必要	GitLab Flow のような、環境ブランチがある戦略がフィットしやすい
大規模	20名〜	・リリース計画が複雑化し、責務分離のためのブランチ構造が必要 ・複数チーム間の依存を調整するため「明確な禁止事項」が必須	Git Flow の develop / release など、多段階の安定ブランチを使う戦略

役割構成による影響

• QAチームが存在する
  • リリース前に「QA が検証するためのブランチ」が必要
  • 例）release ブランチ、staging ブランチなど
• レビュー文化が強い（全 PR 必ずレビューを実施する、など）
  • squash や rebase を使った「綺麗な履歴」重視文化が合う
• バックエンド / フロントエンド / インフラ など職種が分かれている
  • 職種ごとの依存関係管理のため、大きめのブランチ構成のほうが安全
  • feature ブランチの生存期間が長くなる傾向

チーム構成を踏まえた判断ポイント

• 人数が増えるほど、ルールは「厳格化」せざるを得ない
• 職種が多いほど、ブランチ数は増える傾向がある
• レビュー文化が強いほど、履歴の美しさや merge 方式が重要になる

→「どれくらい複雑なブランチ戦略を許容できるのか」という判断に直結

2. メンバーの Git スキル

メンバーの Git スキルは、ブランチ戦略の複雑度を左右します。

レベル	できること	チームとして考えること
初心者	pull,merge, push などの基本操作	ブランチ構成を単純化し、原則禁止を明確にする
中級者	コンフリクト調整、rebase, squash などの操作	ある程度複雑なブランチ運用も可
上級者	歴史改変、rebase 前提の運用、複数ブランチの併走管理	TBD などの高速開発も安定して運用可能

→ スキルが低いメンバーが多いほど 、「単純化・明文化・フェールセーフ」が重要
また、ある程度「煩雑な履歴に対する許容」を求められる場面が出てくる可能性もあります。

3. リリース頻度（デプロイ頻度）

リリース頻度は、安定ブランチ数や merge ポリシーに大きく影響します。

リリース頻度	特性	向いている戦略の傾向
毎日〜毎時間	高速デリバリ、CI/CD必須	GitHub Flow / TBD
週1〜月1	QA期間がある、バッファが必要	GitLab Flow / Git Flow をベースとした簡略化運用（※）
四半期〜半年	大規模、承認プロセスが多い	Git Flow（release ブランチが活躍）

※ Git Flow をベースとした簡略化運用：Git Flow の develop / release ブランチを使うが、運用コストを下げるため release ブランチを必要時のみ作る、などの軽量運用を想定

→頻度が低い場合、「安定ブランチが増える → 手動作業が増える → ヒューマンエラーも増える」という構造が考えられるため、慎重な判断が必要
この場合に想定されるケースとしては、以下のような例が挙げられます。

release ブランチと main ブランチを両方更新する必要がある場合、
同じ修正を 2 回マージしたり、hotfix の逆流順序を手作業で判断する必要が出てきます。
　
また、複数の安定ブランチへ同じ修正を backport する際（main → release → hotfix など）、どこまで反映済みかを人が管理する必要があり、反映漏れや cherry-pick ミスが起きやすくなります。
　
このように「人が判断する場面」が増えるほど、ミスのリスクは跳ね上がります。

4. プロジェクトの種類

Web アプリ、LTS 製品、SaaS、モバイルアプリなどによっても運用は大きく変わります。

• SaaS：常に最新版提供 → TBD / GitHub Flow が合う
• モバイルアプリ：ストア申請がある → release ブランチ文化が必須
• ライブラリ・SDK：サポートバージョンが並行 → Git Flow の develop ＋ release ブランチ運用が有効
• LTS版を提供するプロジェクト：過去バージョンのパッチ運用 → hotfix が多くなるためブランチ数が増える

→ プロダクトのリリース特性が、最低限必要な安定ブランチ数に影響

下位観点：技術的な運用ルール

上位観点の整理ができたら、次は運用ルールを具体化していきましょう。
ここでは「何をどこまでルール化するか」の考え方を明確にします。

1. 安定ブランチの数

判断のポイント

• QA 環境の有無
• リリース承認フローの厳しさ
• リリース直前の動作確認フローがどこにあるか

安定ブランチが少ない場合の特徴

• 運用が軽くなる
• 衝突や未検証コード流入のリスクが増える
  • ※ブランチが少ないからこそ回避できるミス（逆 merge など）もある

安定ブランチが多い場合の特徴

• 品質の担保がしやすい
• その代わり手動作業が増え、人的ミスのリスクも増大
  • 例）main に入れるつもりが release に入れた、など

→「どこまでのリスクを CI/CD や文化で吸収できるか」も判断ポイント

2. ブランチ総数

ブランチ総数が少ない運用の特徴（TBD / GitHub Flow）

• PR の寿命が短い文化が必須
• 1〜数日単位の高速サイクル
• 小さな差分で頻繁にマージ

ブランチ総数が多い運用の特徴（Git Flow / QA が長いプロジェクト）

• リリース計画が明確
• 並行開発や QA 調整が発生しがち
• 結果、「未完コードの長期保持」が起きやすい

→ 本質は「未完のコードをどのくらいの期間持ち越して良いか」という文化の問題
ブランチ総数の議論は、往々にして実質的には「長期間生き残る feature ブランチ（= 未完のコード）をどこまで許容するか」の問題に帰結します。

長寿命の feature ブランチが増えると以下のリスクが高まります。

• 大規模なコンフリクト
• どのブランチに何が入っているのかが把握困難になる
• レビューが重くなる
• リリース準備が複雑化する

したがって、ブランチ総数は「技術力」よりも、「開発スピードや QA の運用とどう折り合いをつけるか」の文化的判断とも言えるでしょう。

3. マージ方法

merge モードは履歴操作の都合上、多くの場合「レビューの前後で履歴が変化するかどうか」が意思決定に影響します。

merge commit

• 履歴を完全に残すため、チーム履歴を時系列で追える
• 雑多なコミットが増える

squash merge

• 1つの作業ブランチ＝1コミットになるため、履歴が綺麗になる
• 元コミットが追えなくなる

rebase

• 線形な履歴になるため、安定ブランチを綺麗な状態に保ちやすい
• 衝突リスクがあり、初心者が操作するには不向き

cherry-pick

• 必要なコミットだけ反映させる
• 緊急対応向けで、多用すると履歴が分岐しやすい

→ 採用する merge モードは「チームのレビュー文化」とセットで決める必要がある
merge モードは単に履歴の美しさだけで決めるものではなく、「レビューをどのように運用しているか」と密接に関わります。
これは「ブランチ戦略 × mergeモード × レビュー文化」の視点で考える必要がある、とも言えるでしょう。

merge commit：
「履歴の正確性 > 美しさ」を重視するレビュー文化に向いている
→ブランチの種類によってマージ方法を変えるなど、ルールが複雑化すると人的ミスのリスクなども高まるため、そうした要素を排除するために「画一的に merge commit を使用する」という手法を選択するケースもある
　
squash merge：
「PR 単位で意味をまとめたい」「レビュー完了後のコミット変動はNGとする」文化に向いている
　
rebase：
「PR のレビュー中に rebase しない」という厳格な運用が必要
※メンバー全員が rebase を使いこなせるスキルであることが前提
　
cherry-pick：
hotfixなど、使用箇所は限定的にするべきで、日常運用としては使わない方が良いとされる
→多用すると履歴が枝分かれし、「この修正はどのブランチに入っていて、どこに入っていないのか」を人が管理することになる

4. 禁止事項（フェールセーフ）

禁止事項と言われるとネガティブなルールに見えますが、実際は「安全性をどこで保証するか」を明確にするための設計です。
ブランチの保護設定を追加する、 CI/CD 側で検知ができるようにするなど「仕組み」側で安全性を保証することも多いかと思います。
ここでは、そうした「仕組み」以外で安全性を保証するケースとして「運用ルール」の側面について考えていきたいと思います。

現場でよくある禁止事項、運用ルールの例としては、以下のようなものが挙げられます。

• feature → feature ブランチの作成禁止
  • 依存が複雑化し、片方のマージ待ちで進行が止まるリスク
  • マージ順を考慮しない操作を行うと、安定ブランチに意図しない状態で取り込まれるリスクもある
• release ブランチへの直接 push 禁止
  • QA 済みコード以外が混入するリスクを回避
• main → develop へのマージ禁止 （Git Flow 文脈）
  • 安定ブランチから未検証コードを逆流させない（※）
• PR レビュー依頼後の rebase 禁止
  • レビュー後に履歴が書き変わる事態を防ぐ
• feature ブランチは数日以内に必ずマージ or 廃棄
  • 放置ブランチの乱立防止
  • 例）feature ブランチはマージ直後に delete する、など
• 安定ブランチへの直接コミット禁止
  • 第三者の確認を必須にし、誤って安定ブランチを壊してしまう事態を防止
  • 例）ブランチルールを設定し、対応内容のコミットは必ずPRを経由させる、など

→ これらはすべてフェールセーフ設計であり、「ミスが起きても壊れない運用」を作るためのルール
ただ、個人的にはできるだけ「仕組み」側で安全性を保証できるようにチーム・プロジェクトを作っていくのが良いと考えています。
どれだけ厳格に管理したとしても、手動で作業する以上、どうしても人的ミスのリスクは付きまとってしまうと思いますので…。

※「main → develop へのマージ禁止」の補足：

Git Flow では「main = 本番と完全同期」「develop = 次リリースに向けた開発コード」という役割分担があります。
　
ここで main → develop を許してしまうと、
「リリース後に hotfix を main に取り込み、開発ブランチにも反映する」
という「意図した場合」以外の逆流が起きやすく、誤って develop が巻き戻るなどの事故に繋がります。
　
そのため、Git Flow では「main → develop は “hotfix のみ”（＝管理された例外）」と明示し、それ以外を禁止する文化が多いです。

チームの「規模」「信頼性」「スピード感」に応じて、これらの軸のどこに寄せるかが運用戦略の骨格になります。

おわりに

いかがでしたでしょうか。
今回は、チーム特性に応じた Git ブランチ戦略を選択する際の観点を中心に整理してみました。

「なんとなく今の運用にやりづらさを感じている」「自分のチームに適したブランチ運用はどれなんだろう」
そんな疑問を持ったとき、この記事がブランチ運用を見つめ直すきっかけになれば幸いです。

次回は、今回取り上げた観点が実際の現場でどのようにトレードオフとして衝突するのか、その関係性を整理していきたいと思います。

以上です。最後まで閲覧いただきありがとうございます。

参考

• https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/choosing-git-branch-approach/git-branching-strategies.html
• https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/choosing-git-branch-approach/best-practices-for-git-based-development.html
• https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/
• https://about.gitlab.com/ja-jp/blog/gitlab-flow-duo/
• https://gitlab-docs.creationline.com/ee/topics/build_your_application.html