GitHub PR reviewルールの作り方
PR reviewは、形式だけでなく、何を見るかを決めておくことが大切です。チーム、外注、Codex作業では、確認担当とmerge条件を明確にします。
このページでわかること
- review担当と確認項目を決める
- Secrets、個人情報、意図しない変更を見る
- CI、表示、SEOタグ、設定ファイルを確認する
まず確認すること
- 変更したファイルと目的が合っているか見る
- スマホ表示や公開URL確認が必要か判断する
- mergeしてよい条件をPR上で確認する
やってはいけないこと
- reviewを形式だけで終わらせる
- 差分を読まずにmergeする
- AI作業結果を丸ごと採用する
安全寄りに進める手順
- 対象のrepo、branch、PR、Actions runを確認する。
- Secrets、APIキー、token、.env、個人情報が差分やログに出ていないか見る。
- 必要な場合は値を停止または再発行し、影響範囲を整理する。
- 変更は小さなbranchとPRに分け、CIとreviewで確認する。
CodexやAI作業時の注意
AIに作業を渡す時は、対象ファイル、触らないファイル、確認項目を明記します。認証情報や実際のキー値は本文、Issue、PR説明、ログ、レポートに残さないようにします。
一次情報で確認する領域
Actions、Secrets、PR、repository visibility、workflow permissionsは仕様が変わることがあります。実作業前にはGitHub Docsで最新の説明を確認してください。