git-flow の話をしよう

そろそろ git-flow 自分用にまとめておかなければ。なエントリ。

とは言っても、git-flow 自体は何も難しくない。環境が古いと動かないので、環境構築とかアップデートで挫けることはあるかもしれない。あとはそもそも git のお作法を知らないと、git-flow 自体も難しく見えると思う。ちなみに私はそれらのものたちを Homebrew で管理している派。

インストールの手順等は別の機会に譲るとして、ここにはまっさらなリポジトリで git-flow を使いはじめる際の流れだけをまとめる。リポジトリは、その、もう作ってある前提で、進めるね?

まずは init

まず init する。init すると「まだブランチがないから今作ろうぜ!」と言われ、「プロダクションリリースは master でいい?」「その前段階は develop でいい?」とフランクな感じで訊かれるので、さくさくエンターで答える。

$ git flow init

あらかじめ使うであろうブランチやタグのプリフィクスについて、この時点で設定される。この設定が終わると、自動的に initial commit が走り、手元のブランチが develop に切り替わる。参考までに init した後になんて訊かれるのかを以下に記しておく。

$ git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

GUIで確認すると、こんな感じになってるはず。

init 後の状態

config あれこれ

正直何をしているかはよくわからないけれど、粛々と以下の config を叩く。

$ git config branch.master.merge refs/heads/master
$ git config branch.master.remote origin
$ git config branch.develop.merge refs/heads/develop
$ git config branch.develop.remote origin

そして master と develop にそれぞれ push する。まずは master に。

$ git push origin master
origin master に push した状態

続いて develop にも。

$ git push origin develop
origin develop に push した状態

GUI で見ると、それぞれ head がどういう状況になっているのかが分かる。

feature で作業する

基本、 develop で作業することはない。feature にブランチ作って、作業したものを develop にマージする流れになる。以下は feature/hitoyam-no-work というローカルブランチを作って作業する時の流れ。

$ git flow feature start hitoyam-no-work

start を叩いた後は、以下のような行が表示される。

$ git flow feature start hitoyam-no-work
Switched to a new branch 'feature/hitoyam-no-work'

Summary of actions:
- A new branch 'feature/hitoyam-no-work' was created, based on 'develop'
- You are now on branch 'feature/hitoyam-no-work'

Now, start committing on your feature. When done, use:

git flow feature finish hitoyam-no-work

親切にも、「今 feature/hitoyam-no-work にいるから、好きに作業しなさいよね、終わったら finish するんだからね」と教えてくれている。GUI で確認すると、確かにローカルにブランチができている。

ローカルに feature/hitoyam-no-work ができている状態

作業する

作業したら、 feature/hitoyam-no-work に作業内容を add & commit する。

$ git add .
$ git commit -m "hello this is test commit hello"

当たり前だが、ローカルがひとつ先に進む。

作業内容を add & commit した状態

feature finish してみる

feature での作業を終えたら、先ほど指示された通りに finish してみる。

$ git flow feature finish hitoyam-no-work

すると、こんな感じの行が表示される。

$ git flow feature finish hitoyam-no-work
Switched to branch 'develop'
Updating 7f27d38..eff888f
Fast-forward
test | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test
Deleted branch feature/hitoyam-no-work (was eff888f).

Summary of actions:
- The feature branch 'feature/hitoyam-no-work' was merged into 'develop'
- Feature branch 'feature/hitoyam-no-work' has been removed
- You are now on branch 'develop'

よく見ると、feature/hitoyam-no-work は華麗に削除されている。そして develop にいることになっている。まるでベルトコンベアに乗っているようだ。GUIで見ても、わー確かに消えてるー消えてるわー。

feature/hitoyam-no-work が削除されて develop にマージされた状態

リリース的な処理をする

master = production releases と設定してあるため、develop から master にマージしないといけない。この時に、 tag を設定する必要がある。書式に合わせて書くだけだから難しいことをするわけではない。

$ git flow release start 0.1/201308091630

これは「2013年8月9日の16:30 にバージョン 0.1 としてリリースしますよー」という意味。何時何分まで書かないといけないようなので、適当に入れとく。そうすると以下の行が表示される。

$ git flow release start 0.1/201308091630
Switched to a new branch 'release/0.1/201308091630'

Summary of actions:
- A new branch 'release/0.1/201308091630' was created, based on 'develop'
- You are now on branch 'release/0.1/201308091630'

Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:

git flow release finish '0.1/201308091630'

先ほどの feature 作業の時と同じく、start して finish する流れになるため、最後の行で「終わったら finish してよねー」と教えてくれている。

release start 後の状態

release finish する

というわけで finish してみる。

$ git flow release finish 0.1/201308091630

じつはこの後で「ひゃっ!?」ってなる。なんかよくわからないけどコメントを求められるのだ。いつまでたってもこの感じに慣れなくて「ひゃっ!?」ってなる。

マージのコメントを求められている状態

しかし、特におかしなマージもしてなくてコメント入力の必要がないなら、普通に終わらせてよい。

問題はマージコメントを終了させた後に出てくる方。タグメッセージというのを求められるので、こちらは何か入力しておく。正直、これがどこで使われるのかは知らない。誰か教えて。

tag に付けるメッセージを求められている状態

ちなみにタグメッセージ付けずに進めようとすると、以下のように「やり直しー!」って言われる。

fatal: no tag message?
Tagging failed. Please run finish again to retry.

だからちゃんと入れましょうね。そしてちゃんとタグメッセージ入れて進めた状態を GUI で見ると、tag が付いて master が先頭に来ているのが分かる。

tag が付いて master が先頭に来ている状態

あとは origin master に push するだけ。これでローカルの master と リモートの origin/master が揃っている状態になり、リリースブランチでの作業が終わったことになる。

リリースブランチであるローカルの master と リモートの origin/master が揃っている状態

その後のデプロイやなんかについては、案件状況により事情が違うだろうから、まとめはここで終了。feature しか書かなかったけど、hotfix とかも同じくやればよい。

git flow 難しくない、そして便利

というか、そもそも面倒を減らすためのツールなので、面倒が減っている。はず。

こんな感じで作業していくと、以下の画像のような感じでブランチが伸びていく。例に挙げているのは究極にシンプルなパターンなので、実際の開発環境ではもっと独創的な枝ができているに違いない。恐ろしい。

リリースを繰り返すとこんな感じになるの図

進歩している証拠ではありつつの悩み

全然関係ないけど、最近の悩みはメモ代わりのブログエントリ達が「本当の意味での初心者さん」に伝わらない内容になってきてそうなこと。そもそもエンジニアは自力で Qiita とか見ろよ! って話だし、せっかくだからデザイナー的な立ち位置の初心者さんにも伝わるように書けた方がいいのかなって。

とはいえ、非力なデザイナーがよっこいしょーって頑張って開発環境にコミットしているこの感じ、そりゃやればやるだけ覚えていくわけで、むしろ覚えてない方がおかしいだろって話なわけで、割愛したい内容も増えるわけで、割愛しないとむしろ要点がわからなくなるわけで?

でもまぁ言うほど悩んでない。元々は自分のためのメモ書きだし、自分と同じくらいの理解度の人にとっては参考になることもあろうし、まぁいいかって。あと言うほど進歩しているわけでもないしな...。これからもこんな感じで淡々とメモメモ。うん。

関連してるかもしれないさそるの過去エントリ

当サイト『蠍は留守です』はIE6のCSS対応を廃止しました。
新しいバージョンのブラウザでご覧下さい。

古いブラウザのままご覧になる場合には、ここをクリックしてCSSを切った状態でご覧下さい。