新人エンジニアの諸君！今日も元気にPRを出していきましょう！
タイトルは明確に
タイトルは簡潔、明確に付けましょう。英語は好みが分かれるのでチームのコミットログを見ながら決めてください。
良いタイトルの例
「DBの呼び出し時にコネクションをプールさせない変更」
「IE9で罫線が表示されない問題への対応」
「申請が行なわれた際にエラーになる件への対応」
悪い例
その1「高橋さんが3日前に言っていた件」
一体何を…？
その2「feature/yousan/201901/admin/fix-event-button」
PR元のブランチ名を使うパターン。でもブランチ名って見づらいんですよね。
その3「fix #1000」
Issueやチケット番号で対応させたいのはわかるのですが、ひと目でわかりません。
PRの本文にFix #1000などと書いて参照しましょう。
確認できる方法を書く
確認できるURLがあればそのURLを記載しましょう。
もしくは手元でチェックアウトして動かしてもらうのであればその旨を書いてください。
ブランチごとに独立したデプロイが可能であれば確認が捗ります。
なければ画像（スクリーンショット）や動画があれば良いです。
「百聞は一見にしかず」です。
誰に何を確認してもらいたいか
見た目や動作、コードなどでレビュワーが複数候補になる場合があります。
また何を確認して欲しいのか、コードなのか動作なのか設計なのか、思っている範囲で書きましょう。
チームとしてレビューの対象となるかどうかは別の問題ですが、不明な箇所は積極的に明らかにしましょう。
開きっぱなしのPRとなって放置されてしまいます。
コンフリクトは修正する
コンフリクトを含んだPRは 取り込めません。
テストも同様です。
PRを出した人の責任でコンフリクト、テスト失敗を解消しましょう。
コンフリクトの解消になれていない場合にはGitをおさらいして、先輩エンジニアにヘルプを要請しましょう。
ブランチを開きっぱなしにしない
ブランチを作る -> 修正 -> PR -> レビュー -> (繰り返し） -> マージ
ブランチを開いてからPRで取り込まれるまでに日数がかかると大変です。コンフリクトが発生したり、任されたIssueの目的があやふやになったり、他の人が修正してしまったりする可能性が高まります。
概ね3日以内にマージされることを目標としましょう。
PRはあなたのもの
PRはあなたのものです。他の人のものではありません。
あなたの実績ですし、あなたの貢献ですし、あなたの仕事です。
誇りと責任を持って取り組みましょう。
よいPRライフを！