読者です 読者をやめる 読者になる 読者になる

愛と勇気と缶ビール

ふしぎとぼくらはなにをしたらよいか

gitのbranch ruleを決める際の個人的チェック事項

git

プロダクションリリースの前は適当でいい。適当にfeature branch切ってガンガンmasterにmergeしてdeployすればいい。変更の種類によっては直接masterにぶち込んでしまえばいい。スピード感が大切な時期なので、いちいちbranch ruleを定めてそれを遵守すること自体が時間の無駄。

プロダクションリリースからそれ以降は、

  1. プロダクションにはmasterとか特定のbranchではなくtagを切ってそれをdeploy。切り戻す先は一つ前のtag
  2. プロダクション以外の環境には特定のbranchをdeploy。切り戻すというか修正の仕方は適宜。

という感じにする。それに加えて、「feature branchを現在の最新安定版にmergeした状態で結合testが出来るbranch」があるとよい。「それってmasterじゃね?」masterではない。masterをこの目的に使うと、「feature branchをmasterにmergeしたはいいものの、なぜか動かないんだぜ状態」の時にmasterからbranchを切れなくなり、万が一の時のhotfixがし辛くなってしまう。 (tagからbranch切る?なんかやだなあ、それ)

例えばgit-flowではdevelop branchがそのbranchに相当する。「特別にそれ用のbranch作らなくても、git pull origin masterとかでfeature branchを最新に追い付かせればいいじゃん?」という考え方もあるが、それだと複数のfeature branchを特定のreleaseにまとめたい時に厳しくなる。が、それで問題がないような開発サイクルであればそれでもいい。

というわけで、どういうbranch ruleをとるにせよ

  1. 「最新安定版はどれか」が明確であり、問題発生時にどこに切り戻せばいいか分かる
  2. 最新安定版相当にfeature branchを取り込んだ状態のtestが出来る

という2条件が最低限満たされていればよいのではないか。後は好み + 開発サイクル次第な気がしている。

入門Git

入門Git