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

Gitのブランチ戦略とは｜参画先ごとに運用が違う理由

ブランチ戦略とは、ブランチの作り方・統合の仕方・リリースへの載せ方を定めた取り決めです。ツールの機能ではなく、チームの合意事項にすぎません。だからこそ現場ごとにばらつきます。

戦略が決めているのは、おおむね次の3点です。

• どのブランチが「常にリリース可能な状態」を保つ基準ブランチなのか

• 作業ブランチをどの単位で切り、どれくらいの期間で統合するのか

• リリースと緊急修正（hotfix）をどの経路で本番に届けるのか

戦略が分かれる根本はリリース形態にある

分岐点は技術力の差ではありません。そのプロダクトが「いつリリースされるか」で決まります。

日に何度もデプロイできるWebサービスでは、リリース専用のブランチを長期間維持する意味が薄くなります。一方、パッケージ製品や業務システムのように、バージョン2系と3系を同時に保守する必要があるなら、バージョンごとの系統を残す設計が要ります。

例外もあります。継続的デプロイのWebサービスでも、金融・医療などリリース前に外部審査や受入テストの期間が制度上必要な領域では、リリースブランチを残す運用が選ばれることがあります。

参画者が最初に直面するのは「合わせるか、提案するか」

外部人材として入ると、自分が慣れた戦略と参画先の運用がずれている場面に必ず当たります。ここで独自ルールを持ち込むと、レビュー負荷を上げるだけで終わります。まずは合わせる。その判断が実務上は正解になるケースが大半です。

主要3モデルの違い｜Git Flow・GitHub Flow・trunk-based

結論として、3モデルは「基準ブランチをいくつ持つか」と「作業ブランチをどれだけ生かすか」で区別できます。

Git Flow｜バージョンを明示的に管理する製品向け

Vincent Driessen氏が2010年に公開したモデルです。main（master）とdevelopという2本の長期ブランチを持ち、feature・release・hotfixの3種類の補助ブランチを使い分けます。

強みは、リリース前の安定化期間を明確に確保できる点です。releaseブランチ上でバグ修正と最終確認を進めながら、developでは次のリリース向け開発を止めずに続けられます。

弱点は構造の複雑さです。ブランチが5系統になるため、マージ経路の取り違えやhotfixの取り込み漏れが起きやすくなります。原典であるA successful Git branching modelには、2020年に著者自身の注記が追加されています。継続的デリバリーを行うチームにはより単純なワークフローを推奨する一方、明示的にバージョン管理する製品や複数バージョンを並行サポートする製品には今も適合する、という趣旨です。

GitHub Flow｜継続的デプロイのWebサービス向け

mainブランチと作業ブランチだけで構成される、最も単純なモデルです。mainから作業ブランチを切り、プルリクエストでレビューを受け、mainへマージしてデプロイします。developもreleaseもありません。

学習コストが低く、参画者のオンボーディングが早いのが利点です。mainが常にデプロイ可能である前提に立つため、CIによる自動テストとブランチ保護がセットになります。詳細な手順はGitHub公式のGitHub flow解説で確認できます。

trunk-based development｜デプロイ頻度を最大化するチーム向け

全員がtrunk（main）という単一の共有ブランチへ頻繁に統合していくモデルです。作業ブランチを使う場合も寿命をごく短く保ちます。

DORAやtrunk-based developmentの解説では、ブランチを数時間からごく短期間に保つという考え方が基本に置かれ、複数人が関わり数日から数週間かかるフィーチャーブランチと対比されています。実務上も、作業ブランチを使うなら1〜2日以内の統合を目安にするチームが多く見られます。ただしこれは運用の勘所であり、日数を1日超えたら該当しない、という種類の線引きではありません。

未完成の機能をmainに入れるため、フィーチャーフラグで本番への露出を制御する運用と組み合わせるのが定石です。前提条件は軽くありません。テスト自動化が成立していないチームが形だけ導入すると、mainが壊れた状態で放置されます。詳しい原則はtrunkbaseddevelopment.comとDORAのTrunk-based developmentにまとまっています。

なおDORAの2025年レポートでは、AI活用の効果を得るうえでも小さな単位で作業を進める前提が重要だと整理されています。ブランチを小さく短く保つ発想は、AI支援が入っても変わっていません。

3モデル比較表

ミニFAQ：GitLab Flowはどの位置づけですか

GitHub Flowに環境ブランチ（staging・productionなど）やリリースブランチを足した中間的なモデルです。継続的デプロイに寄せつつ、環境ごとの段階リリースを残したい場合に採られます。本記事の判断軸では、GitHub Flow寄りの運用に環境管理を加えたものとして扱って差し支えありません。

ブランチ戦略の選び方｜4つの判断軸

結論から言えば、次の4軸を順に当てはめると候補は1つか2つに絞れます。技術的な好みから入ると決まりません。

判断軸1：複数バージョンの並行保守が必要か

必要ならGit Flow系が第一候補になります。バージョン2系の緊急修正を、3系の開発を止めずに出せる構造が要るためです。不要なら、この時点でGit Flowを外して構いません。

判断軸2：リリースに外部の承認プロセスが挟まるか

受入テストや外部審査が挟まるなら、リリース候補を固定できるブランチが要ります。GitHub Flowのままだと、承認待ちの間にmainが進んでしまい、何を承認したのかが曖昧になります。

判断軸3：自動テストでmainの健全性を担保できるか

担保できているならtrunk-based developmentが視野に入ります。担保できていないなら、レビューとマージ前チェックで品質を守るGitHub Flowから始めるのが現実的です。この判定は、CIの実行時間と失敗時の扱いを見ると付きます。GitHub ActionsやGitLab CIでPR単位のテストが動き、失敗時にマージがブロックされているかが分かれ目です。

判断軸4：フィーチャーフラグを運用できるか

trunk-based developmentを本格的に回すなら、未完成の機能を隠したまま統合する仕組みが要ります。フラグの追加・削除を管理する運用まで含めて回せるかが判断点です。回せないうちは、GitHub Flowで運用しながら整備を進めるほうが安全です。

判断フロー（この記事の整理）

この表の使い方には注意点があります。上から順に当てはめることです。下の質問だけを見てtrunk-basedを選ぶと、並行保守の要件を取りこぼします。

運用ルールとして明文化する4項目

戦略を選んだだけでは運用は回りません。結論として、明文化すべきは命名規則・マージ方式・ブランチ保護・寿命の上限の4つです。ここが曖昧な現場ほど、参画者ごとに流儀がばらつきます。

ブランチ命名規則

feature/、fix/、hotfix/ のようなプレフィックスと、チケット番号の付け方を決めます。チケット番号を含めておくと、後からブランチと課題の対応を追えます。

マージ方式（merge commit・squash・rebase）

3方式のどれを使うかは、履歴の読み方の設計そのものです。

• merge commit：分岐と統合の経緯がそのまま残ります。Git Flow系と相性が良い方式です。

• squash merge：PR単位で1コミットに潰します。mainの履歴が読みやすくなり、GitHub Flowでよく選ばれます。

• rebase merge：直線的な履歴になります。運用は美しいものの、共有済みブランチのrebaseは事故につながるため、ルールの徹底が要ります。

重要なのは統一することです。方式が混在した履歴は、障害調査のときに読み解きづらくなります。

ブランチ保護とレビュー必須設定

mainへの直接pushを禁止し、レビュー承認とCI成功をマージ条件にします。設定の項目はGitHub公式の保護されたブランチについてに整理されています。この設定は口頭ルールより強力です。人の注意力に頼らず機械的に守れます。

ブランチ寿命とPRサイズの上限

明文の基準を置くと守りやすくなります。ただし具体的な数字に業界標準があるわけではありません。チームの内部基準として決める性質のものです。実務では、作業ブランチの寿命を数日以内に収め、PRは1回のレビューで読み切れる大きさに抑える運用が採られるケースが多い印象です。上限行数を明記するチームもありますが、値はレビュー体制によって変わります。レビューの進め方そのものはコードレビューの作法で整理しています。

フリーランスが参画先のブランチ戦略を見極める手順

結論として、参画初日から3営業日のうちに読み取れます。ドキュメントが整備されていない現場でも、リポジトリ自体が運用の記録になっているためです。

初日に確認すること

• ブランチ一覧を見て、長期ブランチが何本あるか（mainのみか、developがあるか）

• 保護ブランチの設定内容（直接pushの可否、必須レビュー数、必須チェック）

• CONTRIBUTING.md やリポジトリ内のWikiにブランチ運用の記載があるか

2〜3日目にリポジトリから読み取ること

ドキュメントに書かれていない実態は、履歴に出ます。

• 直近30件程度のマージの形（マージコミットが残っているか、squashで潰れているか）

• 作業ブランチが切られてからマージされるまでの日数の分布

• hotfixに相当する修正が、どの経路で本番に入っているか

• リリースタグの付け方と間隔

ここで宣言されている戦略と実態がずれている現場は珍しくありません。「うちはGit Flowです」と説明されても、releaseブランチが半年前から動いていないことがあります。その場合は実態に合わせます。

暗黙ルールの拾い方

明文化されていない作法は、質問の仕方で引き出せます。「ブランチ運用のルールはありますか」と聞くと「特にないです」と返ってきがちです。具体の場面で聞くほうが確実です。

• 「前回のhotfixはどのブランチから切りましたか」

• 「レビュー承認は何人必要ですか。緊急時の例外運用はありますか」

• 「マージはsquashで揃えていますか」

参画直後の立ち回り全般はフリーランス常駐で評価される立ち回りにまとめています。

ミニFAQ：参画先の戦略に違和感があるとき、すぐ改善提案をしてよいですか

初回更新前の提案は、原則として慎重にしたほうが無難です。まず既存運用で成果を出し、その上で具体的な課題（コンフリクト解消の工数、リリース事故の発生状況など）を観測データとして示すと通りやすくなります。提案のタイミングとしては、レトロスペクティブやリリース振り返りの場が自然です。

ケース別｜参画先タイプごとに見られる運用

受託開発・SI

検収と納品が区切りになるため、リリースブランチを持つ運用が見られます。顧客環境ごとにブランチを分けているケースもあり、同一機能の修正を複数ブランチへ展開する作業が発生しがちです。参画時は、展開漏れを防ぐ手順が決まっているかを確認しておくと安全です。

自社Webサービス

実務上は、GitHub Flowか環境ブランチを加えた運用が採られるケースが多い印象です。mainマージがそのままデプロイに直結する現場もあるため、マージのタイミングとリリース時間帯の取り決めを最初に押さえます。デプロイがGitOpsで組まれている場合は、ArgoCDのようなツールがマージ後の反映を担当します。

スタートアップ・小規模チーム

明文化されたルールが存在せず、事実上のtrunk-based developmentになっていることがあります。ただし自動テストが薄い状態でのtrunk運用は、mainが壊れるリスクを抱えます。参画者としてはまずCIの整備状況を確認し、必要ならテストの拡充から着手する提案が現実的です。

よくある失敗と対策

長生きブランチによるコンフリクト

2週間放置したブランチは、マージ時に数十ファイルの衝突を起こします。対策は単純で、こまめに最新のmainを取り込むことです。取り込み方はチームの標準に合わせます（マージで取り込む現場もあれば、rebaseで揃える現場もあります）。日次で追従しておけば、衝突は小さいうちに解消できます。

参画者が前の現場のルールを持ち込む

squashで統一されている現場にマージコミットを持ち込む、といったケースです。履歴の一貫性が崩れ、レビュアーの負荷が上がります。最初のPRを出す前に、直近のマージ形式を確認するだけで防げます。

hotfixのdevelop取り込み漏れ

Git Flow系で最も多い事故です。mainへ当てた緊急修正をdevelopへ戻し忘れると、次のリリースで修正が消えます。対策は、hotfixのPRテンプレートに「developへの取り込み」をチェック項目として入れておくことです。

CIが落ちたままマージされる

必須チェックが設定されていない現場で起きます。ブランチ保護でマージ条件に組み込めば機械的に防げます。CIツールごとの設定はJenkinsや前述のGitHub Actionsの記事も参考になります。

ブランチ戦略の理解が評価につながる場面

参画者としての評価は、実装速度だけで決まるものではありません。既存運用を壊さずに入れることは、チームから見ると明確な価値です。

実務で効くのは、次のような場面です。

• 参画初週から、誰にも運用を質問し直させずにPRを出せる

• リリース手順の暗黙ルールを早期に把握し、デプロイ事故を起こさない

• 運用の課題を、感覚ではなく観測（コンフリクト頻度・リードタイム）で説明できる

こうした立ち回りは契約更新の判断材料になります。参画後の実績づくりの進め方はフリーランス単価を上げる参画後3ヶ月で整理しています。自分が現在どのくらいの単価を狙えるか確認したい場合は、無料のフリーランスエンジニア単価診断で目安を把握できます。CI/CDやGit運用の経験を活かせる案件を探す場合は案件一覧から条件を絞り込めます。

まとめ

ブランチ戦略は、リリース形態から逆算して選ぶものです。並行保守が要るならGit Flow系、継続的デプロイのWebサービスならGitHub Flow、自動テストが揃っているならtrunk-based development。この順で判断すれば大きく外しません。

• ブランチ戦略が決めているのは、基準ブランチの数・作業ブランチの寿命・リリース経路の3点

• 3モデルの違いは優劣ではなく、前提とするリリース形態の違い

• 選定は「並行保守 → 外部承認 → テスト自動化 → フィーチャーフラグ」の4軸を上から当てはめる

• 明文化すべきは命名規則・マージ方式・ブランチ保護・ブランチ寿命の4項目

• 参画者はまず既存運用に合わせる。初日から3営業日で保護設定・マージ形式・ブランチ寿命を確認する

• 宣言された戦略と実態がずれている現場は珍しくないため、履歴から実態を読み取る

次のステップとしては、参画先のリポジトリで保護ブランチの設定画面と直近30件のマージ履歴を確認するところから始めてみてください。運用の実態は、そこにほぼ書かれています。

参照した一次情報は以下のとおりです。

• A successful Git branching model（Vincent Driessen）

• GitHub Docs：GitHub flow

• GitHub Docs：保護されたブランチについて

• Trunk Based Development

• DORA：Trunk-based development

• Atlassian：Gitワークフローの比較