git-flowの概要
メリット
- 本番リリースしたデータと、制作中のデータの区別が明確になる
- 修正、リリース、機能追加などのいくつもの種類の違う作業を並行して進められる
- リリースした内容の調査が簡単になる
- git-flow用のコマンドでほとんどの管理を行えるので、操作マニュアルを用意しやすい
デメリット：Git Flowの推奨はもう止めましょう！
- 表面的には複雑です
- 目的の異なるブランチが複数あるので競合が発生しやすい
- gitでは、ブランチにコミットしている人とのマージの競合数はそのブランチで作業している人の数とともに増加して行きます。
git-flowの構成
登場するブランチ（6種類）
masterブランチ
- プロダクトとしてリリースするためのブランチ
- リリースしたらタグをつける
- コミットしてはいけない（マージのみ）
developブランチ
- 開発ブランチ
- リポジトリ作成直後のmasterブランチから派生させる（ブランチを作る）
- コミットしてはいけない（マージのみ）
featureブランチ
- 機能の追加・変更・バグ修正を実施する
- developブランチから派生される
- developブランチへマージされる
- developブランチへマージされた後は削除される
- 一つの変更に対し一つのブランチが生成される
- ブランチの名称は変更内容がすぐにわかるような名称にしなければならない
- 「feature/****_bugfix」のように階層化されることが多い
releaseブランチ
- 製品をリリースするための準備を実施するブランチ
- 製品リリースのための関連作業を実施するブランチ
- releaseブランチ上で発見したバグに関しては、コミット（修正）を実施してよい。
- releaseブランチ上で実施したコミットは、masterブランチ、及びdevelopブランチへマージされる
- 各ブランチへのマージが完了したら、releaseブランチは削除される
hotfixブランチ
- 製品リリース後に発覚した不具合に対しての対策を実施するためのブランチ
- リリース済みのmasterブランチから派生させる
- hotfixブランチ上で発見したバグに関しては、コミット（修正）を実施してよい。
- hotfixブランチ上で実施したコミットは、masterブランチ、及びdevelopブランチへマージされる
- 派生元がmasterになるだけで、操作的にはreleaseブランチと同等
supportブランチ
- 「旧バージョン等をサポートし続けなればならない」場合、旧バージョンの保守、及びリリースを実施する。
- 互換性がある最後のmasterブランチ上のコミットから派生させる
- サポート終了するまで独立してバグフィックスやリリースを行う
- masterブランチとの互換性がなくなる可能性が高い
- masterブランチ側がメジャーバージョンのバージョンアップが行われる可能性が高い
git-flowの使いどころ
git-flowが適している人
- 組織のリリースサイクルが毎月、または四半期ごとである場合、
- チームが複数のリリースと並行して作業している場合、Gitflowは適切な選択と成り得るかも知れません。
- チームが20人以上で並行してリリースに取り組んでいる場合、gitflowはチームを混乱させないように十分なセレモニーを提供し保証してくれます。
git-flowが適していない人
- チームがスタートアップである場合やインターネットに接続しているウェブサイトあるいはウェブアプリケーションに携わっている場合で一日に複数のリリースがある場合は、gitflowは適していません。
- チーム規模が小さい（10人未満）場合、gitflowは作業するには過剰なセレモニーとなり、あまりに多くのオーバーヘッドが掛かってしまいます。
