もふもふ技術部

git-flowをシミュレーションしてみる


環境

  • Mac OS X 10.7.5 Lion
  • git version 1.8.1.2
  • git-flow 0.4.1

git-flowやるぞ!

git-flowについては下記ページで「A successful Git branching model」の原文が翻訳されている。読むべし。大変素晴らしいことだ!
http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html

まずは既にシミュレーション用として下記のような状態のリポジトリを準備しておいた。

git-flowでは開発用にdevelopブランチを使うので作っておく。

どうやらgit-flowのプラグインがあるらしいのでMacPortsでインストールしてみる。ちなみにgit-flowのルールに従ううえで、このアドオンは必須ではないが、諸々の操作を簡略化してくれるので便利ではある。

既存のリポジトリにgit-flowを適用には下記コマンドを実行。git-flowのルールに従ってブランチを作成することになるのでブランチ名はデフォルトで良いだろう。Enter連打で完了させる。

developブランチをデフォルトにしておく。

では、メンバが開発するためのfeatureブランチを作ってみよう。developブランチから分岐させてfeature-001ブランチを作る。自動的にデフォルトブランチがスイッチされる。

仮にsource_file_A.txtに”update feature-001″と追記して更新する。git diffで確認してみる。ちゃんと更新されている。OK。

gitリポジトリにaddしてcommitする。ちなみに-Aは変更されたファイル・削除されたファイル・新規に追加されたファイルを全部まとめてaddするためのオプションだ。

これでfeature-001の修正は完了したとして、developブランチにmergeする。自動的デフォルトがdevelopブランチにスイッチされた。

あとはdevelopブランチにpushして終了。git-flowに従って開発メンバが行う操作はここまで覚えておけばOK。

続いてはreleaseブランチをシミュレーション。別の開発メンバがfeature-002ブランチを作ってsource_file_B.txtを更新し、developにマージ済みの状態にしておき(上記同様なので手順は割愛)、feature-001とfeature-002を含む状態のリリースを行う。下記コマンドでreleaseブランチが作成される。

適当にREADME.mdでも作ってadd, commitする。

README.md

releaseブランチをmasterブランチにマージする。ん?「タグメッセージがねぇよ?」と怒られてる。

あ、さっきvimが開いたけど何もせず閉じてしまったのが原因っぽい。再度release finishしてタグメッセージに”1.0.0″とか入力しておく。続いてコミットメッセージも入れろといってくるので、デフォルトのまま:wqする。今度はうまくいったようだ。これでmasterブランチとdevelopブランチにマージされたっぽい。続いてgit branchコマンドでreleaseブランチが削除されていることを確認。

最後にmasterとdevelopにpushして完了。あとhotfixの話もあるんだけどこの辺までにしておこう。おつかれさまでしたー

やってみてどうよ?

gitは去年半ばくらいから使っていたのだが、なにぶん一人とか二人で開発することが多かったのでmasterブランチ一本でやっていた。言ってしまえばgitの基本能力が足りてない。そういう事情もあり、このgit-flowがいかに便利なものかという点、判断つかないというのが本当のところ。

ただ、git自体がフレキシブルにブランチ操作が出来る特徴があるため、開発メンバはある一定のルールにそって運用していく必要があるのではないかと常々思っていた。そういう意味では機能単位に区切ってfeatureブランチを作り、開発が終わったらマージするという仕組みは、非常にシンプルでわかりやすくなるので運用がスムーズになるんじゃないのかなと考えている。

The following two tabs change content below.
原田 敦

原田 敦

日本CAWのエンジニア。もふもふ部の部長。得意分野はRuby on Railsを使った小規模WEBアプリケーションを高速で開発すること。週末の楽しみは一人お菓子パーティー。三度の飯より小動物をもふもふするのが好きです。