git-flowについて
git-flowのチートシート
http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html
メリット
hotfix（緊急の修正）とfeature（修正）が明確に区別できる
複数コマンドを一つのコマンドにまとめたことで、マージ先のブランチを間違える等のオペレーションミスを軽減できる
デメリット
巻き戻しの手順などは結局デフォルトのgitコマンドに頼らざるを得ない
すべてのリポジトリのある環境でgit flowをinstallし、git flow initをしないといけない
git-flowは毎日リリースを行うようなチームには向いていない？？
https://gist.github.com/Tomohiro/6737765デフォルトgitの使い方もわからない初心者がgit-flowを理解するのが難しい
IDEとの親和性が良くない（サポートしているIDEもある）
GitHub-flowについて
GitHub-flow図解
http://qiita.com/tbpgr/items/4ff76ef35c4ff0ec8314
メリット
レビューの文化が定着する（たとえレビューできなくても、いやでも変更箇所くらいは頭に入ってくる）
エンジニア以外との連携も視野に入れられる（デザイナーが画像だけ変更してプルリク、ディレクターが設定ファイルだけ変更してプルリク、みたいな）
git-flowのようにインストールは不要
デメリット
- githubを利用できない案件だと、プルリクエストは実現できない
結論
- git-flowはデプロイ感覚が比較的長め（１周間以上）くらいのスピード感の案件でないと、逆に手間がかかりそう
- GitHub-flowは比較的柔軟、プラグインという概念もないため扱いやすい
- GitHub-flowを採用しよう → おそらくこういう考えに至る人が多数派なので、git-flowの利用者が減ってきている・・？
課題
- GitHubを使えない案件ではをプルリクエストをどのように実現するか・・？
- 「何らかの方法による伝達とレビュー」という形に置き換える