最近pull requestを開発フローに取り込みつつあるので(実験中)、適当に方針を策定した。
これは現在のチーム(Railsによるwebアプリの作成プロジェクト)の方針であっておすすめ方針とかではないので、参考程度に。
git-flowとgithub-flowの不格好なキメラです。
1.追加/変更/リファクタリングした部分について、新しいブランチを作ってそれをpushする。この際、最低限、正常系についてのテストを用意すること。ブランチの命名規則は以下を参考に。
f/xxxxx 機能追加/変更
ref/xxxxx リファクタリング
fix/xxxxx バグ修正
release/xxxxx リリース準備
hotfix/xxxxx もぅﾏﾁﾞ無理。。
2.マージ先をdevelopとしてプルリクを作成する。プルリクコメントに、それに関するテストがどれで、どこにあるのか(circles_controller_spec.rbなどファイル名)を書く。
3.その箇所について詳しいか、コードに関する認識を共有したい相手を1名(1名のみ)レビューアとして指名する。
4.レビューアはローカルに対象ブランチを落とし、指定されたテストがそのまま通るか確認する。UIについてや、JSが絡む場合は、該当箇所を実際にブラウザで動かしてエラーが出ないかチェックする。
5.テストが通らない、エラーが出る場合は、コメントで指摘する。作成者はそのブランチで修正して再びpushし、プルリクを更新する。これを繰り返す。
6.そもそも根本的に勘違いしている場合はプルリクを却下する。
7.大丈夫そうならdevelopブランチにマージする。対象ブランチはクローズする。
8.マージした後にバグを見つけたり、リファクタリングしたくなったら、新たなブランチを作ってプルリクする。
レビューアを1人だけ指定することにより傍観者効果を排する。
また、現チームは他人のコードをリファクタリングしたがる血に飢えた野獣が多いので、red→green→refactorのrefactorを別の人に任せてしまうことにしている。
