tl;dr
- 1~2日以上を要するQAやリリース作業を含む開発フローを想定するならgit-flowを使う。
- CIをパスさせて速やかにデプロイするフローを想定するならgithub-flowを使う。
- 初期バージョンのリリース作業（一般的にはQA）が始まるまでは、masterブランチをベースにgithub-flowで十分。
- 自分たちのアプリケーションのリリースフローや品質要求について予め考えておこう。
前置き
世の中にはアプリケーション開発のブランチ運用方法としてgit-flowとgithub-flowというものがあります。 どっちを使うか、もしくは自分たちにどっちが適しているかというのはよくある悩みだと思います。 この記事では、それについてざっくりまとめてみます。
この記事ではgit-flowおよびgithub-flow自体の解説はしません。
git-flow
git-flowはリリースにあたって1~2日もしくはそれ以上の作業が必要になる場合に適したなフローです。
いくつかの機能をまとめてリリース作業に引き渡すときにreleaseブランチを作ってソースをfixします。リリース作業にはQAや（もしあるなら）リリース判定会議、iOSアプリの場合はアプリの審査などが含まれます。
リリース作業中にも次期バージョンの開発は止まらないのであれば、それはdevelopブランチで行われます。
github-flow
github-flowの大前提は機能ごとに開発、masterブランチにmergeして、即デプロイすることです。github-flowの方がgit-flowよりも簡単ですが、この前提を満たせるかどうかを考える必要があります。
例えばA,Bをばらばらに開発した場合に、両方ともを含めたQAが必要となるとgit-flowは成立しません。基本的にはCIのテストや開発者のチェックでOKというフローになってる必要があります。
もし、少人数の開発などで並列して機能開発するケースが稀であるならgithub-flowで構いません。
その他いろいろ
例えば、iOSアプリとそこから叩かれるAPIサーバを開発している場合を考えます。
iOSアプリの更新には審査期間があるため、APIサーバのiOSアプリと連携する部分（API定義など）はgit-flowに従う必要があります。逆に、サーバに閉じてる修正（バグ修正や細かいチューニングなど）はgithub-flowで作業できます。この場合、サーバに閉じている修正はgit-flowで言うところのhotfixと同等に扱っているとも言えます。
また、どっちのフローを使うにしても初期バージョンがリリース準備に入るまではmasterブランチをベースにしてgithub-flow的な運用をすれば十分だと思います。ただ、例えば masterブランチへのpushをトリガにしてtagをうつ みたいなリリース関わる処理をCIに組み込む場合、ちょいちょい余計な処理が走る気持ち悪さがあるかもしれません。許容できるなら許容してしまいましょう。
修正をリリースするにあたってどのようなQAをして、どのような作業が必要になるのか、自分たちのアプリケーションのリリースフローや品質要求について予め考えてみましょう。
なんだか当たり前のことを膨らませて書いたような気がしますが、皆様の参考になれば幸いです。
