1日に何度もデプロイするようなwebサービスとかをターゲットに考えてます。

基本的にルールが嫌いなのでgit(CIも含め)のワークフローは極力シンプルで問題を起こしづらいものにした方がいいな、といろいろ考えてたら次のようなフローに落ち着きました。

GitHub Flowに従う

大筋、GitHub Flowが個人的な最適解です。シンプルで万人が理解しやすく、問題も起きづらいモデルだと思います。

pushごとにCI(jenkinsとかtravisとか)でテストが実行される

大前提ですね

pull requestには変更対象のテストが含まれていなければならない

デザインの修正だけ、とか明らかにテストが不要な箇所の修正ならよいのですが。

pull requestはテストが通らないとマージしてはならない

これはPRされたブランチをmasterにマージした状態のコードに対してテストします。travisとかが勝手にやってくれるやつです。

pull requestは出した本人がマージする

責任持ちましょう。なんとなくmasterで問題が起こった場合にその原因がコードを書いた人ではなくマージした人だと思ってしまう面もあったり、そのあたり責任が分散してしまうので、コードを書いた人がマージしましょう。

force push(git push --force)は禁止

いかに個人ブランチであろうとも一度pushされたブランチの歴史を書き換えるのは禁止です。賛否両論ありそうですがいくつか理由があって

• 「個人ブランチ」の定義が曖昧。pushされている以上全員から閲覧可能な状態であり、もしかしたらそのbranchをfetchしてる人がいるかもしれない
• pull request上で議論が起こってるようなブランチの場合、その議論の全体像が見え辛くなる。そういうケースでは議論が収束したら別のブランチを作ってrebaseしてそれをもう一度PRする

シンプルかつ問題の起きづらい、という観点で単純にforce pushを禁止するのが一番との結論に至りました。

それからデプロイです。

masterにpushされたら自動でデプロイする

GitHub Flowに従えばmasterは常にデプロイ可能な状態であって、それならば勝手にデプロイしてしまえばいいだろう、と。

こんな感じですかね。