【GitHub入門】Approve・Request changes・Dismiss review・Closeの違いとレビュー後の進め方
GitHubでプルリクエスト（Pull Request、以下PR）を作成した後は、ほかのメンバーに変更内容を確認してもらいます。これがコードレビューです。この記事では、Unityの4人チーム開発を例に、Approve・Request changes・Dismiss review・Close pull requestの違いと、レビュー結果の確認方法を説明します。
まず覚えるのは「レビュー」と「PRを閉じる」の違い
| 操作 | 意味 | PRの状態 |
|---|---|---|
| Comment | 質問や意見を送る | Openのまま |
| Approve | 変更を承認する | Openのまま |
| Request changes | 修正を依頼する | Openのまま |
| Dismiss review | 提出済みレビューを無効化する | PR自体は閉じない |
| Close pull request | マージせずPRを閉じる | Closedになる |
1. Submit reviewで選べる3種類
Comment：コメントのみ
「この移動速度はInspectorから変更できますか？」のような質問や提案に使います。承認や修正依頼にはなりません。
Approve：変更を承認
変更箇所と動作を確認し、問題なければ選びます。例：「Playモードで動作確認しました。Consoleにエラーはありません。」
Approveしても自動でmainブランチにマージされるわけではありません。マージは別の操作です。
Request changes：修正を依頼
例えば「プレイヤーが壁をすり抜けることがあります。Colliderを確認してください」のように、場所と問題を具体的に書きます。PRはOpenのままで、修正作業を続けられます。
ブランチ保護ルールなどがない場合、Request changesだけで必ずマージが禁止されるわけではありません。授業では修正依頼が残っている間はマージしないルールにします。
2. レビュー結果は相手にどう届く？
Submit reviewすると、レビュー結果とコメントはGitHub上のPRに記録されます。PR作成者はConversationで「approved these changes」「requested changes」などの履歴を確認できます。行ごとの指摘はFiles changedなどから確認します。
GitHubのNotifications（ベルのアイコン）やメールにも、本人の通知設定などに応じて通知されます。ただし、メールを見ない人がいても授業は進められます。
今回の授業ルール
- レビュー担当者はSubmit reviewを押す。
- 担当者はPR作成者に口頭で「レビューしました」と伝える。
- PR作成者はGitHubのConversationと必要な指摘箇所を開く。
- 承認ならマージ担当者に連絡し、修正依頼なら修正する。
口頭連絡は気づいてもらうための補助手段です。正式な記録はGitHubのPRで確認しましょう。
3. Request changesを受けたら？
Aさんがプレイヤー移動のPRを作り、Bさんが壁のすり抜けを指摘した例で考えます。修正するためにPRをCloseしたり、新しいPRを作り直したりする必要はありません。
- AさんはPRのConversationやFiles changedで修正依頼を読む。
- 同じ作業ブランチでUnityの設定やコードを修正する。
- Playモードで動作を再確認する。
- GitHub DesktopでCommitしてPushする。
- 同じPRに追加されたコミットを確認し、Bさんに再レビューを依頼する。
- Bさんは修正箇所を確認し、問題がなければApproveする。
修正をPushしただけで自動的にApproveへ変わるわけではありません。レビュー担当者の再確認を受けましょう。
4. Dismiss reviewとは？
Dismiss reviewは、すでに提出されたレビューを無効化する操作です。例えば、古くなった修正依頼を例外的に無効にする場合に使います。適切な権限が必要で、理由を入力します。レビューコメントや却下の履歴は残ります。
重要なのは、修正依頼を受けてコードを直したからといって、自分でDismiss reviewをするのが通常の手順ではないことです。通常は修正後に再レビューを依頼します。今回の実習ではDismiss reviewを操作する必要はありません。
5. Close pull requestとは？
Close pull requestは、そのPRをmainに取り込まずに閉じる操作です。「同じ機能のPRを間違えて二つ作った」「実装方針が変わり、このPRは使わなくなった」場合などに使います。Closeしても作業ブランチやコミットが自動削除されるわけではありません。必要に応じてPRをReopenできる場合もあります。
「壁をすり抜けるから修正してほしい」はRequest changes、「このPRによる取り込み自体を取りやめる」はCloseです。
6. 2人で練習してみよう
- Aさんが小さな変更をCommit・PushしてPRを作る。
- BさんがFiles changedで差分を確認し、理由を書いてRequest changesを送る。
- AさんはGitHubのConversationで依頼内容を確認し、修正して同じブランチへPushする。
- Bさんがもう一度確認してApproveする。
- チームのマージ担当者が、必要な条件を満たしていることを確認してマージする。
レビューは相手を評価するためではなく、変更を安全に取り込むための作業です。小さな変更でも、何を確認したかを短くコメントしましょう。
よくある質問
Q. メールを見ないとレビュー結果は分かりませんか？
いいえ。GitHubのPRのConversationで確認できます。今回の授業では口頭でレビュー完了を伝え、GitHub上で内容を確認します。
Q. Request changesを受けたらPRを作り直しますか？
通常は作り直しません。同じブランチで修正し、Commit・Pushして再レビューを依頼します。
Q. Approveされたら自動でマージされますか？
いいえ。Approveとマージは別です。
まとめ
Approveは承認、Request changesは修正依頼、Dismiss reviewは既存レビューの無効化、Close pull requestはPRの取り込み中止です。基本の流れは「PR作成 → レビュー → 修正 → 再レビュー → Approve → マージ」。まずはこの流れを身につけましょう。