git-flow is
- Vincent Driessen さんがブログで公開した A successful Git branching model のこと
- または、A successful Git branching modelを補助するためのツールの名称
- ブランチの運用ルール、命名規則を設けることで、
複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる - もっとシンプルなルールにしたものに、
GitHubFlow
がある- 元記事:GitHub Flow
- 日本語訳:github-flow.ja.md
- 小さなサイクルでデプロイするケース向き
この記事では、A successful Git branching modelに登場するブランチについて説明していきます。
※利用する5種類のブランチの前に、運用手順に目を通したほうがイメージが付きやすいかもしれませんm(_ _)m
※個人的な意見には、先頭に を入れています。
利用する5種類のブランチ
git-flowは2種類のメインブランチ ( master
, develop
) と3種類のサポートブランチ ( feature
, release
, hotfix
)を利用します。
メインブランチ
開発の軸となるブランチ
master ブランチ
- 分岐元:なし
- マージ先:なし
- ブランチ名の例:
master
- 特徴
- 本番にリリースできる状態を保つ
- 直接コミットは行わない
- release 、hotfix からマージを行い、タグを作成する
-
タグ名は
release/vX.X.X
がよいと思う
-
タグ名は
develop ブランチ
- 分岐元:
master
- マージ先:なし
- ブランチ名の例:
develop
- 特徴
- 開発中の最新状態を反映する
- 基本、直接コミットは行わない
- feature , hotfix からマージを行う
サポートブランチ
メインブランチでの開発を補助するためのブランチ
feature ブランチ
- 分岐元:
develop
- マージ先:
develop
- ブランチ名の例:他のブランチ名のルールと重複しないもの
-
シンプルに
feature/*
か、
feature/YYYYMM_{案件名}/*
とかするのがいいと思う -
Githubなどを用いてissueと合わせて運用するのであれば、
feature/{issue番号}__*
とか、feature/YYYYMM_{案件名}/{issue番号}__*
としたほうがいいと思う
-
シンプルに
- 特徴
- 新機能の開発を行うのに用いる
- develop へマージする際は、Gitの
-no-ff
オプションも活用する
(一連のコミットを1コミットにまとめる機能) - リモートへPushせず、ローカルでのみ利用する
- Pull Requestも活用するのであれば、Pushしてもいいと思う
release ブランチ
- 分岐元:
develop
- マージ先:
master
とdevelop
- ブランチ名の例:
release-*
-
release/vX.X.X
がいいと思う
-
- 特徴
- リリースの準備作業を行うのに用いる
- バージョンの変更
- 小さなバグフィックス
- master へマージ後、 develop へマージする
完了後、release を削除する
- リリースの準備作業を行うのに用いる
hotfixブランチ
- 分岐元:
master
- マージ先:
master
とdevelop
- ブランチ名の例:
hotfix-*
-
hotfix/*
がいいと思う -
Githubなどを用いてissueと合わせて運用するのであれば、
hotfix/{issue番号}__*
としたほうがいいと思う
-
- 特徴
- 緊急のバグフィックスを行うのに利用する
- master へマージ後、develop へマージする
完了後、hotfix を削除する- 利用用途としては release に似ているが、
develop を経由せずに master へマージできるため
進行中の開発が影響を受けにくい
- 利用用途としては release に似ているが、
運用手順
develop
を作成する
-
master
からdevelop
を作成する
リポジトリ作成直後のみ実施する
機能開発の準備を行う
-
develop
からfeature
を作成するfeature
は開発する機能毎に作成する
機能開発を行う
-
feature
で機能を開発する
ローカルでのみコミットし、pushは行わない
後でfeature
を削除するのであれば、Pushしてかまわないと思う
Pushすれば、WIP Pull Request
やGithubのDraft Pull Request
が利用できる
開発中の最新状態を feature
に取り込む
- 任意のタイミングで
develop
をfeature
へマージする
マージ時のコンフリクトを避けるため
開発済みの機能を develop
へ取り込む
-
feature
をdevelop
へマージする
Githubなどを利用している場合は、PR(Pull Request)を利用する
リリース作業の準備を行う
- リリース準備のため、
develop
からrelease
を作成する -
release
でバージョンの変更や、小さなバグフィックスを行う
リリース完了
-
release
をmaster
へマージし、タグを作成する - 製品をリリースする
-
release
をdevelop
へマージする -
release
を削除する
緊急修正対応を行う
-
master
からhotfix
を作成する -
hotfix
でバグフィックスやバージョンの変更を行う
緊急修正対応を完了する
-
hotfix
をmaster
へマージし、タグを作成する - 製品をリリースする
-
hotfix
をdevelop
へマージする -
hotfix
を削除する
まとめ
オリジナルの概念が発表されたのが、既にかなり前になります。
現在はGithubなどで様々な機能もできていますので、feature
はPUSHしてしまったほうが、
Draft PR (WIP PR)によるレビューや作業状況の把握のためよいと思います。
また、オリジナルは使い終わったブランチは基本的に削除する方針ですが、
後続の開発の邪魔にならないようにブランチ名のルールを決めていけば、
残しておいてもいいと思います。