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

プロダクションリリースの前は適当でいい。適当に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