蠍は留守です考

蠍の輪郭を見つめてふける思惟の痕跡

20170509013806

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? []

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

続いて develop にも。

$ git push origin develop

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 してくださいね」と教えてくれている。

作業する

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

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

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

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で見ても、確かに消えている。

リリース的な処理をする

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 finish する

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

$ git flow release finish 0.1/201308091630

実はこの後で、ちょっとびっくりする。なんかよくわからないけど、コメントを求められるのだ。いつまでたってもこの感じに慣れなくてドキドキする。

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

問題はマージコメントを終了させた後に出てくる方。タグメッセージというのを求められるので、こちらは何か入力しておく。正直、これがどこで使われるのかは知らないが、入力しないとうまくいかない。タグメッセージ付けずに進めようとすると、以下のようにやり直しと言われる。

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

タグメッセージを入れて進めると、tag が付いて master が先頭に来ている。

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

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

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

そもそも面倒を減らすためのツールなので、面倒が減る。はず。


参考URL

Copyright © Hitoyam.