GitHubでのコメント・レビュー機能の使い方（コードレビュー入門）
前回の記事で、`Fork`と`Pull Request`を使い、他人のプロジェクトに貢献する第一歩を踏み出しました。しかし、Pull Requestを送っただけでは、開発は完了しません。ここからが、チーム開発の醍醐味であるコードレビューの始まりです。
コードレビューとは、他の開発者があなたの書いたコードをチェックし、フィードバックをくれるプロセスのことです。これにより、バグを早期に発見したり、より良い書き方を学んだり、チーム全体のコード品質を向上させることができます。この記事では、GitHub上で円滑なコミュニケーションを取り、効果的なコードレビューを行うためのコメント・レビュー機能の使い方を詳しく解説していきます。
コードレビューの基本：Pull Request上でのコミュニケーション
コードレビューの中心となる場所は、あなたが作成したPull Requestのページです。このページには、あなたの変更内容に関するすべての情報が集約されており、ここでのコミュニケーションがプロジェクトの品質を左右します。
GitHubのレビュー機能は、大きく分けて2種類あります。
- コメント (Comment): 特定のコード行や、Pull Request全体に対して、気軽に質問や意見を投稿する機能。
- レビュー (Review): 変更全体を正式に評価し、「承認（Approve）」、「コメントのみ」、または「変更要求（Request changes）」の意思表示をする機能。
この2つを使い分けることで、円滑なコミュニケーションが可能になります。
コメント機能の具体的な使い方
まずは、気軽に使えるコメント機能から見ていきましょう。
1. Pull Request全体へのコメント
変更全体に関する一般的な質問や、お礼などを伝えたい場合は、Pull Requestページ下部にあるコメント欄を使います。「Conversation」タブの一番下にあります。
[画像：Pull Requestページ下部のコメント入力欄のスクリーンショット]
テキストエリアにメッセージを入力し、「Comment」ボタンを押すだけで投稿できます。`@ユーザー名`と入力すると、特定の人に通知を送る（メンションする）ことも可能です。
2. 特定のコード行へのコメント
コードレビューで最もよく使うのが、この行単位のコメント機能です。「この部分の変数の名前は、もっと分かりやすい方が良いのでは？」といった、具体的な指摘をするのに最適です。
- Pull Requestのページで「Files changed」タブをクリックします。
- 変更があったファイルの一覧が表示されるので、コメントしたいコードの行の左側にマウスカーソルを合わせます。
- 青い「+」アイコンが表示されるので、それをクリックします。
- テキストボックスが表示されるので、コメントを入力して「Start a review」ボタンを押します。
[画像：「Files changed」タブで、特定の行にコメントを追加している様子]
この時点では、まだあなたのコメントは「保留中（Pending）」の状態です。複数の指摘をまとめてから、最後にレビューとして送信するのが一般的です。
3. 変更提案機能 (Suggestion)
「こう書き換えた方が良い」という具体的なコードを提案したい場合は、コメント欄の上にある「Insert a suggestion」アイコン（`+/-`のようなマーク）をクリックします。すると、コードブロックが挿入され、あなたの修正案を直接記述できます。
[画像：コメント欄で「Insert a suggestion」機能を使ってコードの修正案を提示している様子]
この機能を使うと、Pull Requestの作成者はボタン一つであなたの提案をコードに反映させることができるため、非常に便利です。
レビューを提出する：承認か、変更要求か
複数のコメントを書き溜めたら、最後にそれらをまとめて一つの「レビュー」として提出します。画面右上に表示されている「Review changes」ボタンをクリックしてください。
[画像：「Review changes」ボタンを指している様子]
すると、以下の3つの選択肢が表示されます。
- Comment: 承認や変更要求はせず、単にフィードバックとしてコメントを残すだけの場合に選びます。「ちょっとした質問」や「個人的な意見」などに使います。
- Approve: 「この変更内容は素晴らしい！問題ないので、マージしてOKです」という承認の意思表示です。
- Request changes: 「この変更には修正が必要です。マージする前に、指摘した点を直してください」という変更要求の意思表示です。
[画像：レビュー提出時の3つの選択肢（Comment, Approve, Request changes）が表示されたモーダルウィンドウ]
適切な選択肢を選び、必要であれば全体のまとめコメントを記入して「Submit review」ボタンを押します。これで、あなたのレビューが正式に提出され、Pull Requestの作成者に通知が届きます。
レビューへの対応：指摘を修正して再プッシュする
逆に、あなたがPull Requestの作成者で、他の人からレビューをもらった場合の対応方法も見ておきましょう。
ステップ1: コメント内容を確認し、議論する
指摘された内容について、まずは感謝を伝えましょう。もし意図が分からない点があれば、返信して質問します。すべてのコミュニケーションは、Pull Request上に記録として残ります。
ステップ2: 指摘を元にコードを修正する
レビュアーからの指摘に納得したら、自分のローカルPCでコードを修正します。例えば、`fix-review-comments`のような新しいブランチを切って作業すると、さらに丁寧です。
ステップ3: 追加のコミットをプッシュする
修正が終わったら、新しいコミットを作成し、Pull Request元のブランチ（例: `fix-typo-in-readme`）にプッシュします。
git commit -m "Reflect review comments"git push origin fix-typo-in-readme新しいコミットをプッシュすると、自動的にPull Requestにもその変更が反映されます。新しくPull Requestを作り直す必要はありません。
ステップ4: 対応が終わった会話を解決する
すべての指摘に対応し終わったら、各コメントの下にある「Resolve conversation」ボタンを押して、会話を解決済みにします。これにより、どの指摘が対応済みなのかが一目瞭然になります。
[画像：「Resolve conversation」ボタンが押され、会話が折りたたまれている様子]
すべての会話が解決され、レビュアーから再度「Approve」をもらえれば、いよいよマージとなります。