「PR（プルリクエスト）の書き方を覚えておいたほうがいいですか？」

よく聞かれます。先に結論を書きます。

書き方より、gitの使い方を理解しているほうが大事です。

PRの書き方は、会社によって結構違う

実務に入って分かったことですが、PRの書き方は現場ごとにかなり違います。

  • テンプレートがきっちり決まっている会社
  • タイトルと一言だけでいい会社
  • チケット番号を必ず入れる会社

なので、未経験のうちに完璧な書き方を覚えても、入社先で書き直すことになります。
そこに時間をかけるくらいなら、gitの流れを理解しておくほうが役に立ちます。

どの現場でも共通していること

ひとつだけ、どこでも同じことがあります。

何を変更したか分かるように書くこと

これだけです。
レビューする人は、あなたが何をしたのかを知りたいだけなので。

先に理解しておくgitの流れ

PRを書く前に、この流れが頭に入っているかが大事です。

1. ブランチを切る（作業する場所を分ける）
2. コードを書く
3. コミットする（変更を記録する）
4. プッシュする（GitHubに上げる）
5. PRを出す（この変更を取り込んでいいか確認してもらう）
6. レビューを受けて直す
7. マージされる（本体に取り込まれる）

この流れを説明できると、面接でも困りません。
逆に、テンプレートだけ暗記していても、「なぜブランチを分けるんですか」で止まります。

ブランチを切る習慣をつける

一人で開発していても、機能ごとにブランチを分けてください。

feature/login          ログイン機能を作る
feature/quiz-create    クイズ登録機能を作る
fix/redirect-error     リダイレクトの不具合を直す

こうしておくと、1つの機能ごとにPRが作れます。
すべてをmainブランチに直接書いていると、あとから何をやったか追えなくなります。

実務では、こういう指摘を受けます

参考までに、僕が実務でレビューされて一番多かった指摘を書いておきます。
PRの文章の書き方ではなく、中身のコードについてです。

1. 変数名やルートの命名が統一されていない（これが一番多い）

たとえば「AhaGate」という言葉ひとつでも、書き方はいくつもあります。

Ahagate
ahaGate
AhaGate
aha_gate

どれが正解ということはありません。大事なのは、統一されていることです。

ファイルによって書き方がバラバラだと、読む人が毎回止まります。
ルート（URL）の命名も同じで、/user-list と /userList が混ざっていると気持ち悪いんですよね。

未経験のうちからできる対策は簡単です。
自分の作品の中だけでも、書き方を1つに揃えてください。それだけでレビューする側の印象が変わります。

2. 引数に型を指定していない

その関数が「何を受け取るのか」を書いておく、ということです。

// 指摘される書き方
public function findUser($id)

// 型を指定した書き方
public function findUser(int $id)

int と書いてあれば、数値が来ることが確定します。
読む人が中身を追わなくても分かるし、間違った値が来たときにすぐ気づけます。

3. その関数が何を返すのか書いていない

受け取るものと同じで、返すものも書いておきます。

// 何が返ってくるか分からない
public function findUser(int $id)

// User が返ることが分かる
public function findUser(int $id): User

これがあると、その関数を使う側が中を見なくて済みます。

未経験のうちは意識しづらい部分ですが、ここが書けているだけで「実務を意識しているな」と伝わります。

PRテンプレート（そのまま使えます）

書き方は現場で変わりますが、練習用にはこれで十分です。

## 概要
クイズに「お気に入り」を付けられるようにしました。

## 変更した内容
- favorites テーブルを追加
- お気に入りボタンを一覧画面に追加
- 押したときに画面を切り替えずに反映されるようにした

## なぜこの実装にしたか
毎回ページを読み込み直すと、勉強のテンポが止まると思ったため。

## 詰まったところ
ボタンを押しても反映されなかった。
原因は、送信先のURLの書き方が間違っていた。

## 動作確認
- [x] お気に入りに追加できる
- [x] 解除できる
- [x] 別のユーザーのお気に入りが見えない

ポイントは「変更した内容」と「詰まったところ」です。
この2つが、そのまま面接の回答になります。

コミットメッセージの書き方

PRより先に見られることもあるので、ここも書いておきます。

✕ update
✕ 修正
✕ aaa

○ ログイン後のリダイレクト先を修正
○ クイズ一覧にお気に入りボタンを追加

コミットが「update」ばかりだと、どこかからコピーしてきたのではと疑われます。
機能単位でコミットして、何をしたか一言で書いてください。

一人開発でもPRを書くと得すること

  • 面接の回答が自動的に貯まる（何に詰まって、どう直したか）
  • 自分の理解の浅いところに気づける（書けない＝分かっていない）
  • あとから見返せる
  • 入社後、そのまま同じ動きができる

面接でよく聞かれるのは、この2つです。

「作っていて、一番大変だったところはどこですか？」

「なぜこの実装にしたんですか？」

PRを書いていれば、具体例で答えられます。
書いていなければ「うーん……特には」で終わります。

よくある質問

Q. 一人開発なのに、レビューする人がいません。
A. それでも書く価値があります。書けないところが、自分の理解が浅いところです。

Q. きれいなPRを書けないと落とされますか？
A. 落とされません。書き方は入社後に現場のやり方を覚えます。それよりgitの流れを説明できるかのほうが見られます。

Q. 型の指定は必須ですか？
A. 未経験の段階では必須ではありません。ただ、書いてあると評価は上がります。実務では確実に指摘される部分です。

まとめ

  • PRの書き方は現場ごとに違う。先にgitの流れを理解する
  • どこでも共通なのは「何を変更したか分かるように書くこと」だけ
  • 機能ごとにブランチを切って、機能ごとにコミットする
  • 実務で一番指摘されるのは命名の統一。作品の中だけでも揃える
  • 引数の型と、返り値の型も書けると強い

PRの体裁を整えることに時間をかけるより、gitの流れを説明できるようにするほうが先です。
そこができていれば、書き方は入社後にすぐ覚えられます。

次に読む記事

ポートフォリオの無料添削をしています。命名や書き方の統一も含めて見ています。LINEから送ってください。