俺のオレオレgit-flow
背景
- 一昨年末くらいにgit-flowを採用していた
- 良いんだけど、結構めんどくさいなーと思うところがあった
- 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用)
- masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る
- ただ本番をそれで運用するわけにもいかない
- リリースタイミングとかある
- masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない)
- git-flowとgithub-flowの中間くらいのフローで運用することに
git-flowの気に入ってる点とそうじゃない点
気に入っている点
- 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop)
- hotfixが便利
めんどくさい所
- releaseブランチ毎回作る必要性をあまり感じない
- バージョニングする必要性もあまり感じない(オープンソースやモジュールでもない限り)
- deploy時に自動でtagを打てばいい
- メインブランチをdevelopにするという押し付けがましさ
採用しているフロー
結果として以下の様な感じで運用することにした。
- メインブランチはmaster
- リリース用にreleaseというブランチを並列で走らせる
- マージは全て--no-ff
という感じ。運用フローは以下。
- 開発が一段落したら、masterをreleaseにマージ。確認とテストが終わったらdeploy
- deployスクリプトに自動でtagを打たせる(deploy/YYYYMMDD-hhmmss形式)
- masterは通常通り開発を進める
- releaseに問題や、すぐに入れたい修正が発生した場合はhotfixブランチを開ける
- 修正を行い、hotfixの先頭のテストをグリーンにする
- hotfixブランチをreleaseに向けてp-rを送る
- レビュー後、hotfixをreleaseとmasterにマージ
- releaseはテストの終了を待たずに本番にdeployして良い(理由は後述)
以下補足。
- ちょっとした修正だったらreleaseで直接直しちゃって、そのコミットをmasterにcherry-pickしてもいいかもね
- ブランチ名のルール
- hotfixは"hotfix/"で始まる
- topicブランチは、"feature/"とか"fix/"とかで始まる(特に厳密な縛りはない)
- ブランチ名の末尾には、"-iss999"というようにissue番号を入れる
- hotfixブランチを開けているときは他のhotfixは開けない(もちろん直接コミット入れるのも厳禁)
ブランチ名は例えば、"fix/gift-iss999"とかそういう感じになる。末尾にissue番号入れておくと以下のように色々捗る。
- p-rをissueに紐付けるとか(最近非推奨だけど…)
- コミットログに"ref #999"とか転記しやすい
- ブランチをpushしたら自分にアサインされるとか(これやりたいけどやってない)
- レビューするときにどのissueに関係あるのかわかりやすいとか
hotfixブランチを開けている時に他のhotfixを開かないようにするのは、hotifxをreleaseにマージした際にreleaseブランチとhotfixの先頭が同じ内容になるから。つまり、hotfixの先頭のテストが通ればreleaseにマージしてすぐdeployして良いという寸法。
平行して複数のhotfix走らせたい場合は、後続の修正や時間の掛かりそうな修正を"hotfix-topic/"というprefixのブランチ名で修正をおこなって、現在開いているhotfixの反映が終わったら、新たにhotfixを切り直して、そっちにマージするとかそういう感じにしている。
topicブランチをmasterにマージするときにmasterとの乖離があって追随する必要がある場合、masterを一旦topicブランチにマージするか、rebaseするかはお好きにどうぞという感じ。