##ブランチ戦略とは
「機能Aと機能Bの開発を同時に進めたいが、各々影響を与えあわない状況下で同時に開発を進めたい」といった場合に活躍する仕組み。
masterブランチという現実世界に対して，別のブランチという，複数のパラレルワールドを作るイメージ。
http://gihyo.jp/dev/serial/01/hackgirlsgit/0006
※SAPでいうところの開発機⇒検証機⇒本番機のランドスケープ定義と移送管理を複雑にしたイメージ。
##Git-flowのブランチ戦略とは
・developブランチ
開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。次に紹介するfeatureブランチなど、他のブランチで行った作業は、ここにマージされる
・featureブランチ
主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにfeatureブランチを作成し、作業を行う
・releaseブランチ
リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブランチを作成し、微調整を行う。releaseブランチを作成することで、リリース準備と次のバージョンに向けた開発のコードを分けることができる
・masterブランチ
リリースしたソースコードを管理するためのブランチ。リリース作業を行うと、releaseブランチはmasterブランチへマージされて、リリースタグが打たれる。開発者は、このブランチへのコミットは行わない
・hotfixブランチ
リリースされたソフトウェアに緊急の修正を行うためのブランチ。このブランチでの修正内容は、すぐにリリースされるので、hotfixブランチはリリースを管理するmasterブランチへマージされる
##運用イメージ
1,featureブランチで各機能の開発やバグフィックス
2,featureブランチで単体テスト
3,developブランチへマージして
4,ソフトウェアをリリースする段階でreleaseブランチを作成
5,細かいドキュメントの修正やバグフィックス
6,準備が終わってリリースする際には、リリースブランチをmasterブランチへマージし、リリースタグを打つ。
※ソフトウェアリリース後、緊急のバグへの対応は、ホットフィックスとしてリリース。
http://www.atmarkit.co.jp/ait/articles/1311/18/news017.html
##各社のブランチ戦略
・カウルのブランチ戦略
http://techblog.housmart.co.jp/2016/06/22/git-workflow/
・Gitのブランチ戦略
http://nnhrsk.hatenablog.com/entry/2017/02/19/210436
・SAPのブランチ戦略
SAPも短納期開発のためブランチ戦略のページを作成している
https://www.sap.com/japan/services/rapid-deployment/lending-sales-service-banking.html