Gitflowを知ろう！利用時のルールについて

相変わらずGit勉強中です。
今回はGitを活用する上で重要となるモデル、ルールであるGitflowについて整理していきます。
なお、弊社でもGitflowをベースに管理を行っています。

Gitflowとは

GitflowとはGitにおけるリポジトリの分岐モデルであり、ルールのことを指します。
それぞれのブランチを明確に定義し、複数人での開発時にそれぞれが好き勝手にブランチを作成し混乱することを防ぎます。

下図はその概念図です。

※Vincent Driessen氏が提唱した「A successful Git branching model」を参考に横向きに焼き直したものです。

下記は一般的な各ブランチの定義です。

master:
プロダクトとしてリリースする用のブランチ。リリースしたらタグ付けする。
※このブランチ上での作業は行わない

develop:
開発用ブランチ。コードが安定し、リリース準備ができたらreleaseへマージする。
※このブランチ上での作業は行わない

feature:
機能の追加用。developから分岐し、developにマージする。

hotfixes:
リリース後の緊急対応（クリティカルなバグフィックスなど）用。
masterから分岐し、masterにマージすると共にdevelopにマージする。

release:
プロダクトリリースの準備用。
リリース予定の機能やバグフィックスが反映された状態のdevelopから分岐する。
リリース準備が整ったら、masterにマージすると共にdevelopにマージする。

メリットとしては下記のようなものがあります。

• 本番リリースのリポジトリと開発中、修正中のリポジトリを明確に区別することで本番に紛れ込むことを防ぐ
• 開発、修正毎にリポジトリを作成でき、リリースタイミングに関わらず並行して作業が可能
• リリース後の緊急対応が開発、修正と独立して対応可能（昔、たまに緊急対応リリース時に開発中の別機能が紛れ込む怪現象が・・・）
• 履歴によりリリース内容を後から追跡可能

開発 ～リリースの流れ

開発

1. developブランチからfeatureブランチを切る（feature/XXXXXXブランチ）

git checkout develop
git checkout -b feature/XXXXXX
git push -u origin feature/XXXXXX

2. feature/XXXXXXブランチで開発

git add
git status
git commit
git push

3. 開発終了後、feature/XXXXXXブランチをdevelopブランチにマージ（ローカルリポジトリ）

git checkout develop
git pull
git merge feature/XXXXXX

4. developリポジトリをリモートにpushする（リモートブランチ）

git push

リリース

1. developブランチからreleaseブランチを切る（release-XXXXXXXブランチ）

2. 確認し、問題なければrelease-XXXXXXXブランチをdevelopブランチ、masterブランチにマージ

3. masterブランチにタグ付け

緊急対応

1. masterブランチからhotfixesブランチを切る（hotfixes/XXXXXXXブランチ）

2. 修正対応後、hotfixes/XXXXXXXブランチをdevelopブランチ、masterブランチにマージ

3. masterブランチにタグ付け

SourcetreeでのGitflow

Sourcetreeではこれらの作業を機能として提供しているのでそちらを使うのも有効ですね。

まとめ

複数人での開発の場合、モデル、ルールがあるのは良いことです。
熟練者ばかりであれば阿吽の呼吸で問題なく運用できるのでしょうが、私のような未熟者はこのようなモデルがあることにより、なんとかついていけそうです。