レビューと記録を残す
テクノロジ系 ／ pr — Pull Request ワークフロー
レビューと記録を残す
— Pull Request の役割 —
このトピックが終わると
- PR が「何のためにあるか」説明できる
- GitHub 上で PR を作成できる
- 差分（diff）を読める
- PR をマージしてブランチを削除できる
章 1 — マージ前にレビューを挟む
ブランチを直接マージするとどうなるか
feature/login ──●──●──●
↓ merge（即時）
main ───────────● ← バグが混入しても気づかない誰もコードを確認していない。
小さなミス・設計の問題が本番に入る。
PR = マージの「申請」
feature/login ──●──●──●
↓ PR 作成
レビュー（差分を確認・コメント）
↓ 承認
main ───────────● ← 確認済みのコードだけ入る変更を本番に入れる前に「確認の関所」を置く。
章 2 — PR の作り方
手順の全体像
1. ブランチで作業・commit
↓
2. GitHub に push
↓
3. GitHub Web で PR を作成
↓
4. レビュー・承認
↓
5. マージ → ブランチ削除push 後に GitHub を開く
git push origin feature/login
GitHub のリポジトリページを開くと
「Compare & pull request」バナーが表示される。
クリックして PR 作成画面へ。
PR 作成画面で確認する3点
base: main ← 取り込み先（これに merge される） compare: feature/login ← 自分のブランチ（これが merge される）
| 項目 | 書くこと |
|---|---|
| タイトル | 何をしたか（1行） |
| 説明 | なぜしたか・レビュアーへの補足 |
| 差分タブ | 自分で確認してから出す |
章 3 — レビューに対応する
レビューコメントとは
レビュアーが差分に対してコメントを書く。
「この変数名、もう少し分かりやすくできますか？」 「ここ、エラーハンドリングが抜けていそうです」 「LGTM 👍」（= Looks Good To Me = 承認）
コメントは「指摘」ではなく「品質を一緒に上げる対話」。
修正の対応フロー
レビューコメントを受ける ↓ ローカルで修正 ↓ git add → git commit ↓ git push（同じブランチに push） ↓ PR に自動で追加される（新しい commit として） ↓ レビュアーが再確認 → 承認
修正 push の例
# レビュー指摘を修正してから git add login.php git commit -m "fix: 変数名を userName に変更（レビュー対応）" git push origin feature/login
ブランチが同じなら PR に自動で追記される。
新しい PR を作り直す必要はない。
レビュー対応後の PR の状態
PR #12 「feat: ログイン機能を追加」
commit a3f1b2c feat: ログイン機能を追加
commit 9d8e7f6 fix: 変数名を userName に変更（レビュー対応） ← 追加
↑
push するたびに PR に積み重なる変更の経緯が PR に全て残る。
「なぜこうなったか」が後から追跡できる。
章 4 — 差分（diff）を読む
diff の見方
- return "Login failed" ← 削除された行（赤） + return "ログイン失敗" ← 追加された行（緑）
確認するポイント:
- 意図しないファイルが変更されていないか
- デバッグコードが残っていないか（
print,console.log） - シークレット・パスワードが含まれていないか
まとめ
push ブランチを GitHub に送る PR 作成 「main に取り込んでほしい」と申請 レビュー 差分を確認・コメント 修正 push 同じブランチに push → PR に自動追記 マージ 承認後に main に統合 ブランチ削除 マージ後は不要なので削除
PR はコードレビューの場であり、変更履歴の記録でもある。
「誰が・なぜ・この変更を入れたか」が後から追跡できる。
→ 次のトピック conflict で衝突の解消方法を学ぶ