git-flowで辿る開発の道

お久しぶり過ぎました、sandmarkです。
趣味プログラマもここまで来ると芸術だなと思いつつ、
最後に(自力で)書いた記事がいつですか、半年以上前ですか。
継続は力なりって言うけれど、僕のように継続できない人間は弱っていくばかりですねー。

挨拶もそこそこに git のお話。
これもかなり前に知って衝撃を受けつつ記事にはしていなかったのですが、
git-flow というものがあるんですね。

これは git のプラグインとして働き、
git の長所であるブランチを最大限に活かしつつ、
かつ分散型の弱点である「中央(みんなから参照されるところ)にあるリポジトリのログを汚さない」
という点において、抜群の効力を発揮してくれます。

そもそも git は「多機能すぎてどういうスタイルがいいのかわからん」というのが
僕のような詳しくない人にとっては結構よくある感触だと思うんですね。
何となく dev ブランチ作って、 master にマージして、 push なり何なりする。

それが『その人のスタイル』として確立されていればいいのだけれど、
そうじゃない場合、自信が持てない上に誰かと作業するときに困る。
というわけで、フローチャートが必要なわけです。テンプレというか。

git-flow の主な流れは明確で、「ルールに従っていればそれでいい」というところがお気に入り。

  1. git flow feature start hello ("hello"という機能の実装を開始。 feature/hello ブランチが作成される)
  2. git flow feature finish hello ("hello"実装完了。 feature/hello ブランチは削除され、developブランチにマージされる)
  3. git flow release start 1.0.0 (リリース版1.0.0の準備を開始。 release/1.0.0 ブランチが作成される)
  4. git flow release finish 1.0.0 (リリースすると同時にタグの入力を求められる)
  5. git flow hotfix start 1.0.1-somefix (バグ修正も死角無し)
  6. git flow hotfix finish 1.0.1-somefix
  7. git push

なにこれちょうべんり。
これは単にブランチを作成→削除するだけではなく、
gitのFastForwardや履歴の管理までやってくれている(らしい)ので、
リポジトリが無駄に肥大化するのを防いでくれる役目もあります。

もちろん、非常に強いルールの上で動くものなので、
独自路線を行っている人には却って邪魔になるかも知れませんが。

何よりも、プラグインとして動いてくれるのが嬉しいところですね。
また、コンソールで動かすのならTAB補完は欠かせない、という人のために
GitHub - bobthecow/git-flow-completion: Bash, Zsh and fish completion support for git-flow.なんてものまで用意されています。

とても有名なプラグインなので、Google先生にお頼み申し上げれば資料がざっくざく出てくると思います。
僕はそもそも git に関して詳しくないので「便利ダナー」ということくらいしか感じられませんが、
案ずるより産むが易し、実際に手を動かして使ってみれば、それだけで感覚が掴めると思います。

git-flow公式にはCygwin用なども用意されているので
今更感が物凄いですが、資料や派生版も豊富なので、どうでしょう、騙されたと思って使ってみては。

(github-flowというのもあるらしいので、良さそうなら近々試してみるつもりでいます。)