PullRequestの手引き
https://gyazo.com/3f096a30b194580102eb1e31b29314ba
Pull Requestをつくる
十分な説明になるタイトルをつける
それだけで完結した説明文を書くようにする
Pull Reqには、動機や目的があるはずある。それを書く
「問題 → 解決」か「背景 → 提案」という構成を使うとよい
実装方法について説明する
コードをみれば自明な場合は、「コードを見てほしい」と書く
関連するサイトやissueのリンクを貼る
スクリーンショットは必須
画像はURLではなく画像が展開されるようにしたほうが良い
Gyazoからmarkdownでコピー、もしくは
やらないことがある場合はリストで明示する
作業中のPull Request
作業途中でも積極的にPRをつくる。ほかの人が作業内容や進捗を追いやすくなる
作業途中の場合は、issue labelにWIPやIn Progressをつけて作業途中であることを明示する
リポジトリによってlabelが違うので統一しておいたほうが良さそうshokai.icon
2020-10-26 hiroshi.icon 現在は draft 状態で pull request 作成して、 review 後の修正も Review/QA 外せばよいと思ってるので要らないと思う
レビュー
レビュー依頼であることを明示する
ZenHub 使う場合は Review/QA に移動するのがよさそう hiroshi.icon
レビュワーはレビュー完了であることを明示する
ZenHub ... -> Done hiroshi.icon
誰かひとりから「LGTM」「よさそう」などのメッセージをもらうとレビュー完了
PRがマージはとてもめでたいことなので画像などを使って最大限盛り上げる
便利な画像集
レビュー完了したら基本的にPR主が自分でマージする
たくさんコメントがある場合、[MUST], [SHOULD], [MAY], [質問]などと書くと修正必須なのか、すべきなのか、どちらでもよいのか、伝わって便利です。
よいPull Requestの例
https://gyazo.com/562913018da76b229c4636714c49a6e6
現在の問題と新しい解決が簡潔明瞭
スクリーンショットがあり分かりやすい
動作確認方法が書いてあるので、レビューしやすい。影響範囲をどう捉えているかわかる
https://gyazo.com/b2289f6e2e74b4cd8f110bc83e7a8630
sentryへの送信というわりと検証が難しいものをlocalhostから送信して試している
試し方が書いてある（のでレビューアーも再現可能）
スクショが貼ってある