git-flow調査メモ

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がサポート。

  1. メイン
    1. master…常に、リリース準備完了の状態を持つ。
    2. development…次のリリースのための開発ブランチ。リリースのための開発が完了したら、masterに反映する。そしてタグを切る。
  2. サポート
    1. feature…機能開発のためのブランチ。developから分岐させ、完了したらdevolopにマージする。
    2. release…開発完了後、本番化直前の最後の微調整を行うブランチ。バグの修正など。リリースブランチが切られたら、次のバージョンのfeature開発に入れる。masterとdevelopにマージする。
    3. 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