This request has already been treated.

  1. alt

    誤字訂正

    alt
Changes in body
Source | HTML | Preview
@@ -1,67 +1,67 @@
#git-flow
git-flowはDriessen氏が[ブログ](http://keijinsonyaban.blogspot.jp/2010/10/a-successful-git-branching-model.html)にて発表したgitの開発手法であり、それを実現するツールの名前でもあります。
今回はツールの説明ではなく、ブランチを中心とした開発手法についてまとめます。
#5つのブランチ
git-flowにはmaster, release, develop, feature, hotfixの5つのブランチが登場します。
##メインブランチ
開発のコアとなるブランチ。
![bm002.png](https://qiita-image-store.s3.amazonaws.com/0/28622/7bdb93b1-879d-56e0-5f95-11ccd8c8ee5f.png)
###master
製品として出荷可能な状態であり、アプリケーションが安定して動く状態にする必要がある。
###develop
次のリリースのための最新の開発作業の変更が反映されている状態。このブランチが常に最新。
##サポートブランチ
機能の追跡、製品リリースの準備、製品に起きた問題をすばやく修正すること、などを容易にするためのブランチ。
###feature
分岐元:develop
merge先:develop
![fb.png](https://qiita-image-store.s3.amazonaws.com/0/28622/15c340b4-b45e-bbdc-5444-f25327a27ad6.png)
developからブランチを切り、新機能の開発を行うのに用いる。
ブランチ名はfeature/news_feedなど、実装する機能をfeature/の後ろに書くなどすればいい。
最終的にはdevelopにmergeする。この時、--no-ffオプションを付けてmergeすると、その機能実装に使ったコミットがまとまり、差分の管理が楽になる。
![merge-without-ff.png](https://qiita-image-store.s3.amazonaws.com/0/28622/a36c0ae0-6999-8e66-2bfe-15bc0f5ad839.png)
###release
分岐元: develop
マージ先: develop と master
リリースブランチは develop ブランチから作成される。release/1.0といった感じで切ればいい。
この間に新機能に不具合が見つかった場合は、work/fix_bugなど修正用のブランチをここから切り、修正が終わったらこのブランチにmergeする。
デバッグが終わるまでdevelopにmergeすることは許されない。
-developにmergeされたら、developをmasterにもmergeして安定を確保する。
+developにmergeされたら、developをmasterにもmergeして安定を確保する。
###hotfix
分岐元: master
マージ先: develop と master
![hotfix-branches1.png](https://qiita-image-store.s3.amazonaws.com/0/28622/b67db40d-ca92-261e-48a3-860627ee14f0.png)
リリース後、万が一不具合が見つかったら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