git-flowとは?

Gitの活用ガイドライン。
Gitは自由。運用方法は強制されない。いろいろ配慮が必要。
リリース準備はどう行う？並行機能開発はどう行う？複雑な並行開発に耐える方法をいちいち考えるのは大変。

2010年、Vincent Driessen氏がブログで「こんな感じで運用したらうまくいったよ」というのを報告。
nvie.com

できがいいので広まった。

メリットは？

規約ができる。考える、決める手間が省ける。

バージョンを切って、ある程度長い（数週間とか）スパンでリリースする開発。
常に最新がデプロイされているような開発は”GitHub Flow”のほうが向いている。

GitHub Flow。プルリクエストを投げるやつ。
常にmasterがデプロイされるような、リリーススパンの短い開発に向いている。

学習が大変。Git自体のコマンドを理解していなければならない。
→　専用ライブラリの導入で楽になる！git flowライブラリ

master,developがメインのブランチ。feature,release,hotfixがサポート。

メイン
1. master…常に、リリース準備完了の状態を持つ。
2. development…次のリリースのための開発ブランチ。リリースのための開発が完了したら、masterに反映する。そしてタグを切る。
サポート
1. feature…機能開発のためのブランチ。developから分岐させ、完了したらdevolopにマージする。
2. release…開発完了後、本番化直前の最後の微調整を行うブランチ。バグの修正など。リリースブランチが切られたら、次のバージョンのfeature開発に入れる。masterとdevelopにマージする。
3. hotfix…本番化後のバグの緊急修正用ブランチ。masterから分岐させる。修正後、masterとdevelopにマージする。ホットフィックスはマスター、リリースはデベロプをベースにしている。ほかは一緒。

基本的に以下のとおり。操作対象と操作内容の組み合わせ。

git flow [feature|release|hotfix] [start|finish|publish|pull] [name]

・リモートリポジトリはフォークでなく、共通のがひとつあるだけでいいのか？ →たぶんそう。・ローカルでマージしたdevelopブランチは、リモートにどう反映するのか？ →たぶん普通にプッシュする。

git push origin [ブランチ名]

でプッシュする。
そこは特に専用コマンドはない模様。
release,hotfixで追加したタグは、以下のコマンドでリモートにも追加するのを忘れないようにすること。

git push --tags

（Qiitaで検索すると、リモートへの反映はPull Requestを活用するやり方が紹介されている。元ネタと違うように見えるが派生版か？）

git-flowの考えを発表した元祖の記事 nvie.com

プラグインのGithub リポジトリ(nvie版とavh版がある。以下はaptで導入できるavh版) github.com