#git-flow
git-flowはDriessen氏がブログにて発表したgitの開発手法であり、それを実現するツールの名前でもあります。
今回はツールの説明ではなく、ブランチを中心とした開発手法についてまとめます。
#5つのブランチ
git-flowにはmaster, release, develop, feature, hotfixの5つのブランチが登場します。
###master
製品として出荷可能な状態であり、アプリケーションが安定して動く状態にする必要がある。
###develop
次のリリースのための最新の開発作業の変更が反映されている状態。このブランチが常に最新。
##サポートブランチ
機能の追跡、製品リリースの準備、製品に起きた問題をすばやく修正すること、などを容易にするためのブランチ。
###feature
分岐元:develop
merge先:develop
developからブランチを切り、新機能の開発を行うのに用いる。
ブランチ名はfeature/news_feedなど、実装する機能をfeature/の後ろに書くなどすればいい。
最終的にはdevelopにmergeする。この時、--no-ffオプションを付けてmergeすると、その機能実装に使ったコミットがまとまり、差分の管理が楽になる。
###release
分岐元: develop
マージ先: develop と master
リリースブランチは develop ブランチから作成される。release/1.0といった感じで切ればいい。
この間に新機能に不具合が見つかった場合は、work/fix_bugなど修正用のブランチをここから切り、修正が終わったらこのブランチにmergeする。
デバッグが終わるまでdevelopにmergeすることは許されない。
developにmergeされたら、developをmasterにもmergeして安定版を確保する。
###hotfix
分岐元: master
マージ先: develop と master
リリース後、万が一不具合が見つかったらhotfixブランチを用いて修正を行う。
masterが現在のリリース内容と一致しているので、masterからブランチを切る。
要は、releaseブランチの逆である。
releaseが
develop→release→develop→masterとなっているとしたら
hotfixは
master→hotfix→master→developである。
#まとめ
master, release, develop, feature, hotfixのブランチの役割を把握して運用することで、開発がスムーズに、そして高品質なアプリを作ることができる。
#参考
"A successful Git branching model" 日本語訳
http://keijinsonyaban.blogspot.jp/2010/10/a-successful-git-branching-model.html