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

いつクリはてブロ

いつになったらクリエイティブするの?

ぼくのかんがえたさいきょうのpull request活用方針

技術 雑記

最近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を別の人に任せてしまうことにしている。