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

【Git】【GitHub】Pull Requestを出すときはやること、やったことを明確に書こう

はじめに

Pull requestでソースレビューをよくやると思うのですが
その際、めんどくさくなり詳細に概要レベルのことしか
書かない場合が多々ありました。

そして、若手に「プルリク出すときは、このぐらい書かないとダメだよね」ということを
自分から実践してもらい、チームメンバーからも賞賛の声をもらいまして、
とても嬉しかったので、メモがてら書きます。

Bad

f:id:fujikawa-y:20150912090536p:plain

github.com

Pull requestのタスクに携わっている場合、すぐに内容を判断できて
スムーズにコードレビューをすることができるのですが
「お、○○さんがPull request出してる。見てみるかな!」と見ても
「やったことはわかるけども、仕様がわからないから指摘しづらい」ということにもなります。

確かに早くレビューを終わらせて、テスト環境で動作確認をしたい気持ちは
痛いほどよくわかりますが、ソースレビューで見つかることはたくさんあると
考えており、実際にそこで見つかったこともたくさんあると思います。

なので、Pull requestには少し大変ですが、後の人のことを考えて
詳しく書くことが大切です。

Good

f:id:fujikawa-y:20150912090513p:plain

github.com

ポイント

  • Pull RequestはWIPで運用する。
  • イシューが他の箇所にある場合、必ずリンクをつける。
    • ※今回の場合、同じリポジトリ内にイシューを作成していますが、外部のBTSの場合、リンクをつけてしまう。
  • 実装することをTODOとして一覧化する。
    • ※一覧化する場合、コミット粒度を気にして書く。そうしないとコミット単位でTODOが見難くなってしまう。

まとめ

数年前みたいに特定の人がソースレビューをするということは
なくなってきており、意識してソースを見るメンバーはたくさんいます。
誰に見られてもいいようなPull Requestを意識してやっていきたいものです。

そして、こういう草の根運動を続けて、いつの間にか
それが当たり前のようになっていればと思います。

以下、フォーマットです。自由に使ってください。
また、何かコメントがありましたら、ぜひお願いします。

## Issue Overview and Detail
Create Registration screen of customer.
※BTSやGitHubのISSUEを使っていたら、リンクのみ設定もあり。

## TODO
- [ ] Create Design
- [ ] Create Screen
- [ ] Add Validate