git-flowとは?
Gitの活用ガイドライン。
Gitは自由。運用方法は強制されない。いろいろ配慮が必要。
リリース準備はどう行う?並行機能開発はどう行う?複雑な並行開発に耐える方法をいちいち考えるのは大変。
2010年、Vincent Driessen氏がブログで「こんな感じで運用したらうまくいったよ」というのを報告。
nvie.com
できがいいので広まった。
メリットは?
規約ができる。考える、決める手間が省ける。
どういう開発を想定?
バージョンを切って、ある程度長い(数週間とか)スパンでリリースする開発。
常に最新がデプロイされているような開発は”GitHub Flow”のほうが向いている。
競合は?
GitHub Flow。プルリクエストを投げるやつ。
常にmasterがデプロイされるような、リリーススパンの短い開発に向いている。
git-flowのデメリットは?
学習が大変。Git自体のコマンドを理解していなければならない。
→ 専用ライブラリの導入で楽になる!git flowライブラリ
git-flowの発想は?
master,developがメインのブランチ。feature,release,hotfixがサポート。
- メイン
- master…常に、リリース準備完了の状態を持つ。
- development…次のリリースのための開発ブランチ。リリースのための開発が完了したら、masterに反映する。そしてタグを切る。
- サポート
- feature…機能開発のためのブランチ。developから分岐させ、完了したらdevolopにマージする。
- release…開発完了後、本番化直前の最後の微調整を行うブランチ。バグの修正など。リリースブランチが切られたら、次のバージョンのfeature開発に入れる。masterとdevelopにマージする。
- hotfix…本番化後のバグの緊急修正用ブランチ。masterから分岐させる。修正後、masterとdevelopにマージする。 ホットフィックスはマスター、リリースはデベロプをベースにしている。ほかは一緒。
git-flowプラグインの使い方は?
基本的に以下のとおり。操作対象と操作内容の組み合わせ。
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
プラグインの解説記事
jeffkreeftmeijer.com
チートシート
http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html
チーム開発の運用ワークショップ
d.hatena.ne.jp