Skip to content

Instantly share code, notes, and snippets.

@funwarioisii
Created June 9, 2021 13:47
Show Gist options
  • Save funwarioisii/c4c26d43c0552e63d1839676e50b35b7 to your computer and use it in GitHub Desktop.
Save funwarioisii/c4c26d43c0552e63d1839676e50b35b7 to your computer and use it in GitHub Desktop.
Pull Requestのdescriptionの書き方

Pull Requestのdescriptionの書き方

(社内で公開した記事を少し編集して公開します)
入社してから半年近く、Pull Requestのdescriptionが足りないという指摘を受け続けていました。
最近はその指摘を受けることは減った気がします。

自分ではマシになったと思っていて、それは大体以下のテンプレに沿って書いているからだと思っています。

テンプレ

## 概要
なぜ既存のコードに変更を加えたいか
どういう方針でコードを変更したいか

## 変更点
実際どういう変更をしたか

## 関連Issue
概要にかかなかったりした場合

## 動作確認
どういう手順で自分の変更を確認したか

## その他
- 後回しにしている課題
- デザインレビューやステークホルダーへの確認について
- 参考にした他の実装

これも全部網羅的に書けているわけではなく、ところどころ歯抜けがあったりします。

あと不安が残る実装などは、コードに対してコメントを残すようにしたり、参考にした他の実装へのリンクを書いたりします。
descに書くよりコメントとして返信しやすいかなぁと思っています。

部内のメンバーでも普段触らないところは、過去に部内のメンバーが実装した箇所のリンクを貼っておくと思い出しやすくて良かったりしそうです(これはさっき気づいたので思いつきで書いています。)

参考にしたものとアレンジ

そもそもdescriptionのテンプレに関しては、アプリ開発チームのPRの真似です。
オリジナルのテンプレートには【チェックリスト】があるのですが、これは細かくて自分には厳しかったので省きました。
【スクリーンショット】に関しては別でデザインレビューを受けることが多いので省いています。

【レビューを必要としているところ】はうまく書けないので書いていません。
部内でレビューをする理由は「変更を加えたときに自分が意図しない変更が起きないか」と「変更箇所の相互確認」だと思っています。
意図しない変更を意識するのは難しく、それがわかれば修正しています。また、不安が残る実装に対してはコメントに書いているので良いかなと思っています。

【変更点】に関しては自分は「コード読めばわかるやろw」と思っていたのですが、他の人のレビューをしているうちに、日本語で補足されていたほうが圧倒的に読みやすいことがわかったのでそうしています。当たり前なんだよな…。

以上自分のPRテンプレでした。
すごく今更感のある記事ですが、自分はうまく出来ていなかったんですよね。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment