Git Flowとは？ブランチの役割や開発の流れを初心者向けに解説

はじめに
Git Flowとは
GitとGit Flowの違い
Git Flowの基本構成
Git Flowを使った開発の流れ
おまけ：Git Flowとほかの開発フローの違い
最後に

はじめに

さて今回は、Git Flowとは何かについてまとめたいと思います。

Gitを使ったチーム開発では、次のようなブランチ名を目にすることがあります。

main
develop
feature/login
release/1.2.0
hotfix/login-error

私も仕事でこのようなブランチ名を目にし、他の開発者が当たり前のように活用していたので何なんだこれは・・・と調べ始めたのがきっかけになります。

するとどうやら、Git Flowという考え方が根幹にありそうだったのでせっかくならばとまとめた次第になります。

自分の備忘録も兼ねていますが、皆さんのお役に立てれば嬉しいです！

それでは見ていきましょ～

Git Flowとは

Git Flow（ギットフロー）とは、Gitでチーム開発するときに「どのブランチを何の目的で使うか」を整理したブランチ運用モデルです。

“モデル”と言われると分かりにくいかもしれませんが、要するに「このブランチはこの目的で使おう！」と定めた”考え方”のようなものだと思っていただければOKです。

Git Flowでは主に次の5種類のブランチを使い分けます。

main
develop
feature
release
hotfix

開発中のコード、本番環境のコード、新機能のコードなどを別々のブランチで管理することで、複数人が同時に開発しやすくなります。

Git Flowのメリットとデメリットも簡単にまとめておきますね。

メリットは主に以下が考えられると思います。

メリット	説明
ブランチの目的が分かりやすい	ブランチ名を見るだけで、何の作業をしているか判断しやすくなる。
複数人で並行開発しやすい	機能ごとに「feature」ブランチを分けることで、ほかの開発者の作業に影響を与えずに開発できる。
本番コードを安定させやすい	開発途中のコードを「main」から分離できるため、本番リリース可能な状態を維持しやすくなる。
リリース作業と次の開発を並行できる	「release」ブランチで最終調整を行っている間も、「develop」では次回以降の機能開発を進められる。
緊急修正に対応しやすい	「hotfix」ブランチを使用することで、通常の開発を止めずに本番環境の不具合を修正できる。

一方、デメリットとしては以下が考えられると思います。

デメリット	説明
ブランチ構成が複雑になりやすい	使用するブランチが多いため、Gitに慣れていないメンバーには理解が難しい場合がある。
マージ作業が増える	「release」や「hotfix」を複数のブランチへマージする必要があり、競合が発生する可能性がある。
頻繁なリリースには向かない場合がある	1日に何度も本番リリースするWebサービスでは、Git Flowの手順が負担になることがある。
長期間残るブランチに差分が蓄積しやすい	「develop」や「feature」ブランチに変更が蓄積すると、大きなマージ競合が発生しやすくなる。

GitとGit Flowの違い

Git Flowは、Gitに標準搭載されている機能ではありません。

Git自体が提供しているのは、ブランチの作成や切り替え、マージなどの機能です。

git branch
git switch
git merge

Git Flowは、これらのGitの機能を利用して、次のようなブランチ運用の考え方を定めたものです。

新機能を開発するときは「feature」ブランチを作る
次回リリース用のコードは「develop」ブランチに集める
本番環境の緊急修正には「hotfix」ブランチを使う

ですので、少し勘違いされる部分もあるかもしれませんが、あくまでも先述したブランチ名などはGitが自動的に決めている名前であったり、ルールとして定められているわけではなく、単にチーム内でブランチの役割や開発手順を統一するために使われる、Git Flowというブランチ運用モデルから広まった命名だということです。

Git FlowはGitの機能ではなく、ブランチ運用の考え方だと覚えておきましょう！

GitとGit Hubの違いは以前記事にまとめているのでそちらをチェックです！

【GitHub】Git / GitHubって何？？【Java勉強ログ #2】

GitとGitHubの違いや使い方を初心者向けにわかりやすく解説します。バージョン管理システムの基本や、GitHubの便利な機能、実際の操作方法などを紹介します。GitとGitHubの歴史や特徴も学べます。

Git Flowの基本構成

Git Flowでは、長期間維持する2種類のブランチと、一時的に使用する3種類のブランチを使います。

長期間維持するブランチ
- main
- develop
作業が終わったら削除するブランチ
- feature/*
- release/*
- hotfix/*

Git Flowが提唱された当時は、本番用のブランチ名として「master」が一般的に使われていました。

現在は「main」をデフォルトブランチにするプロジェクトが増えているため、本記事では基本的に「main」と表記します。

ブランチ名は変わっても、本番リリース可能なコードを管理するという役割は基本的に同じです。

それぞれの役割などは以下の通りです。

ブランチ	役割	分岐元	主なマージ先
main	本番リリース可能なコードを管理する	–	–
develop	次回リリースに向けた開発内容を統合する	main	–
feature/*	新機能を開発する	develop	develop
release/*	リリース前のテストや最終調整を行う	develop	mainとdevelop
hotfix/*	本番環境の緊急不具合を修正する	main	mainとdevelop

mainブランチ

「main」は、本番環境にリリースできる安定したコードを管理するブランチです。

通常、開発者が「main」上で直接開発することはありません。

リリース時にはバージョンを示すタグを付けることがあります。

git tag -a v1.0.0 -m "Release version 1.0.0"

developブランチ

「develop」は、次回リリースに向けた開発内容を集約するブランチです。

それぞれの「feature」ブランチで完成した機能が、「develop」へマージされます。

複数の新機能を組み合わせて動作確認する、開発の中心となるブランチです。

feature/*ブランチ

「feature/*」は、新機能を開発するためのブランチです。

基本的に「develop」から作成し、開発が完了したら「develop」へマージします。

develop
   ↓ 分岐
feature/login
   ↓ マージ
develop

ブランチ名には、開発内容が分かる名前を付けます。

feature/login
feature/user-registration
feature/payment

「feature」は「機能」や「特徴」を意味する英単語です。

新しい機能を開発するブランチであることが名前から判断できるため、Git Flowでは機能開発用ブランチの名称として使われています。

ただし、何度もお話している通り、「feature」という名前はGitの仕様で決められているわけではありません。これらはあくまでブランチの目的を分かりやすくするための命名慣習です。

Git Flowの原典では「Feature branches」という役割が定義されました。その後、git-flowツールのデフォルト設定などを通じて、`feature/*`という接頭辞が広く使われるようになりました。

release/*ブランチ

「release/*」は、本番リリース前の最終調整を行うブランチです。

このブランチでは、主に次の作業を行います。

最終テスト
軽微な不具合の修正
バージョン番号の更新
リリースノートの作成

作業が完了したら、「main」と「develop」の両方へマージします。

hotfix/*ブランチ

「hotfix/*」は、本番環境で発生した重大な不具合を緊急修正するためのブランチです。

「develop」ではなく、本番コードを管理する「main」から作成するのが特徴です。

main
  ↓ 分岐
hotfix/login-error
  ↓
緊急修正
  ↓
mainとdevelopへマージ

「develop」にもマージするのは、次回リリースで同じ不具合が再発することを防ぐためです。

Git Flowを使った開発の流れ

ざっくりとイメージを付けるために、「ログイン機能を追加してバージョン1.0としてリリースする」場合を考えてみます。

以下のようなイメージです。

develop
   ↓
feature/loginを作成
   ↓
ログイン機能を開発
   ↓
developへマージ
   ↓
release/1.0.0を作成
   ↓
最終テスト・不具合修正
   ↓
mainとdevelopへマージ
   ↓
mainにv1.0.0のタグを付けてリリース

CLI操作するとこんな感じ、というのも載せておきます。

とはいえ、私もCLI操作には抵抗感があります・・・。初学者あるあるですよね笑。GitHubやVSCodeなどのIDEを使えば簡単にUI操作でできますので、私はそちらでできればいいのかなと思っています。今回はまとめに載せませんが、軽く調べれば色々やり方が出てくると思いますので是非！（いつかちゃんとまとめたい・・・）

1. 「develop」から「feature」ブランチを作成する

git switch develop
git switch -c feature/login

2. 新機能を開発する

git add .
git commit -m "ログイン機能を追加"

3. 「develop」へマージする

git switch develop
git merge feature/login

4. releaseブランチを作成する

git switch -c release/1.0.0

5. 最終テスト後に「main」へマージする

git switch main
git merge release/1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"

6. リリース中の修正を「develop」へ反映する

git switch develop
git merge release/1.0.0

おまけ：Git Flowとほかの開発フローの違い

おまけとして、他の開発フローとの違いも載せておきますね。これが全てではないと思いますが参考程度に！

比較項目	Git Flow	GitHub Flow	Trunk-Based Development
中心となるブランチ	「main」と「develop」	「main」	「main」または「trunk」
機能ブランチ	使用する	短期間使用する	使用しない、または非常に短期間
リリースブランチ	使用する	基本的に使用しない	必要な場合のみ使用する
仕組み	比較的複雑	シンプル	非常にシンプル
リリース頻度	定期的なリリース向け	頻繁なリリース向け	継続的なリリース向け
向いている開発	バージョン管理が重要な製品	Webサービスや小規模チーム	CI/CDが成熟したチーム