• 2025/6/15
• 4分

【Git】ブランチ戦略の種類と使い分け！Git Flow/GitHub Flow/GitLab Flowの違い

＼ アプリをリリースしました ／

友達や家族の誕生日をメモ！通知も届く-みんなの誕生日-

posted withアプリーチ

ブランチ戦略とは？

ソフトウェアを開発していく上でGitを使用してブランチを作成しながら開発を進めていくことが多いと思います。その際にブランチの運用ルールを定めておくことを「ブランチ戦略」と呼びます。個人開発の場合はそれほど気にすることはないですが、複数人での開発の場合はリリースブランチや作業ブランチを明確にし、適切に管理することで予期せぬトラブルやコンフリクトを避けることが可能です。

代表的なブランチ戦略の種類

ブランチの運用ルールはプロジェクトやチームによって様々かとは思いますが代表的なブランチ戦略として4つ紹介しておきます。

• Git Flow
• GitHub Flow
• GitLab Flow
• Trunk Based Development（TBD）

また複数人での開発の場合はPR(プルリクエスト)ベースの開発体制を徹底することがおすすめです。要は実装者とは別の開発者にコードをレビューしてもらい承認をもらってからマージ作業を進める体制です。GitHub Flowでは必須ですが他のブランチ戦略でも導入しておくとデグレや考慮もれを防止することができます。

Git Flow

Git Flow：A successful Git branching model

「Git Flow」は「Vincent Driessen」さんが提唱した長期的な案件向けのブランチモデルです。ブランチの種類が多くなってしまいますが役割が明確でリリースコードを厳密に管理することが可能になります。

develop     ──┬──────┬───────┬─────────────────────▶
              │      ▲       │
feature/*     └─▶────┘       │
                             │
release/1.0                  └─▶─┬⚫︎（デプロイ / 動作確認）
                                 │
main        ─────────────────────└──────┬──────┬───▶
                                        │      ▲
hotfix/1.0.1                            └─▶────┘（mainとdevelopへマージ）

ブランチ

• main(master)・・・リリースブランチ
• develop・・・開発マスターブランチ
• feature/*・・・開発用の一時的な作業ブランチ
• release/*・・・リリース直前の調整ブランチ
• hotfix/*・・・本番環境の緊急バグ修正ブランチ

main(master)・・・リリースブランチ

本番環境にリリースされているバージョンと基本的に同じ内容になる安定版のソースコードを保持するブランチ。このブランチのコードはいつでも本番にアップロードできる状態になる。直接のコミットは禁止され、releaseまたはhotfixブランチからのみマージされる。リリース時にはタグ(例：v1.0.0)を付ける。CI/CDの対象になる。

develop・・・開発マスターブランチ

次回リリースに向けた開発を統合するブランチ。featureブランチはここのブランチに集約されていき、開発段階でのテストや動作確認を行う。CI/CDの対象になる。

feature/*・・・新規開発用の一時的な作業ブランチ

新しい機能や修正を個別に開発するための一時的なブランチ。developから分岐しdevelopにマージされ、マージあとは削除する。例：feature/login-page/feature/payment-api

release/*・・・リリース直前の調整ブランチ

リリース前の最終調整(軽微な修正・バージョン番号の更新・QA)を行うブランチ。。developから分岐しmain/developにマージされる。例：feature/1.0.0/feature/2025-06

hotfix/*・・・本番環境の緊急バグ修正ブランチ

本番環境の緊急バグ修正を素早く反映するためのブランチ。mainから分岐しmain/developにマージされる。本番に反映した後は忘れずにdevelopにもマージしておく。

GitHub Flow

GitHub Flow

「GitHub Flow」はGitHub社が提唱した軽量かつシンプルなブランチモデルです。PR(プルリクエスト)ベースの開発体制で行います。ブランチは最小限の2つのみで構成されます。

main        ──┬─────────┬───────┬──────────┬──────────────▶
              │         ▲       │          ▲
feature/a     └─▶──[PR]─┘       │          │
feature/b                       └─▶───[PR]─┘

ブランチ

• main(master)・・・リリースブランチ
• feature/*・・・開発用の一時的な作業ブランチ

main(master)・・・リリースブランチ

いつでも本番にアップロードできる状態になっているブランチ。リリース時にはタグ(例：v1.0.0)を付ける。直接のコミットは禁止され、main(master)から作業ブランチが分岐され、main(master)へPRを投げ、レビューで承認されれば直接マージされる。

feature/*・・・新規開発用の一時的な作業ブランチ

新しい機能や修正を個別に開発するための一時的なブランチ。main(master)から分岐しmain(master)にマージされる、マージあとは削除する。明確なブランチ命名規則は提唱されていないようですがGIt Flowのようにfeature/*形式にしておくとわかりやすいかもです。

GitLab Flow

Gitlab Flow

「GitLab Flow」はGitlab社が提唱したGitFlowをさらにシンプルにしたブランチモデルです。

main        ──┬──────┬───────┬──────────────────────▶
              │      ▲       │
feature/*     └─▶────┘       │
                             │
staging     ─────────────────└─▶─┬──────────────────▶
                                 │
production  ─────────────────────└─▶────────────────▶

ブランチ

• main(master)・・・メイン開発ブランチ
• staging(pre-production)・・・リリース前(ステージング)ブランチ
• production・・・リリースブランチ
• feature/*・・・開発用の一時的な作業ブランチ

main(master)・・・メイン開発ブランチ

Git Flow/GitHub Flowと異なり開発のメインとなるブランチ。機能開発のたびにfeature/*ブランチここから作成し、マージする。

staging(pre-production)・・・リリース前(ステージング)ブランチ

リリース前の最終調整(軽微な修正・バージョン番号の更新・QA)や動作確認を行うステージング環境となるブランチ。リリースが決まったタイミングでmain(master)から分岐して作成される。

production・・・リリースブランチ

本番環境にリリースされているバージョンと基本的に同じ内容になる安定版のソースコードを保持するブランチ。このブランチのコードはいつでも本番にアップロードできる状態になる。直接のコミットは禁止され、staging(pre-production)からのみマージされる。リリース時にはタグ(例：v1.0.0)を付ける。CI/CDの対象になる。

feature/*・・・新規開発用の一時的な作業ブランチ

新しい機能や修正を個別に開発するための一時的なブランチ。main(master)から分岐しmain(master)にマージされ、マージあとは削除する。例：feature/login-page/feature/payment-api

Trunk Based Development(TBD)

「Trunk Based Development(TBD)」は1つのメインブランチ(=トランク)を中心にすべての開発を行うブランチモデルです。1つのブランチで管理を行うため、「Feature Toggle(機能フラグ)」や 「Canary Release(段階公開)」などと併用して使用されることが多いです。またGitHub Flowと似たようなモデルですが、よりfeatureブランチが短命かつ小さくすることが推奨されています。

main        ──┬─────────┬───────┬──────────┬──────────────▶
              │         ▲       │          ▲
feature/a     └─▶──[PR]─┘       │          │
feature/b                       └─▶───[PR]─┘

ブランチ

• main(master)・・・リリースブランチ
• feature/*・・・開発用の一時的な作業ブランチ

main(master)・・・リリースブランチ

いつでも本番にアップロードできる状態になっているブランチ。リリース時にはタグ(例：v1.0.0)を付ける。直接のコミットは禁止され、main(master)から作業ブランチが分岐され、main(master)へPRを投げ、レビューで承認されれば直接マージされる。

feature/*・・・新規開発用の一時的な作業ブランチ

新しい機能や修正を個別に開発するための一時的なブランチ。main(master)から分岐しmain(master)にマージされる、マージあとは削除する。明確なブランチ命名規則は提唱されていないようですがGIt Flowのようにfeature/*形式にしておくとわかりやすいかもです。

まだまだ勉強中ですので間違っている点や至らぬ点がありましたら教えていただけると助かります。

ご覧いただきありがとうございました。