プルリクエストのレビューについて

レビューを使うと、コラボレーターはプルリクエスト中で提案された変更に対してコメントしたり、変更を承認したり、プルリクエストがマージされる前にさらなる変更をリクエストしたりできます。 リポジトリ管理者は、すべてのプルリクエストをマージ前に承認することを必須にできます。

この記事の内容

プルリクエストのレビューについて

pull request を開いた後、読み取り アクセス権を持つすべてのユーザーは、提案された変更をレビューしてコメントできます。 また、作者がプルリクエストから直接適用できるコード行への特定の変更を提案することもできます。 詳しくは、「プルリクエストで提案された変更をレビューする」を参照してください。

デフォルトでは、パブリックなリポジトリにおいてはどのユーザもPull Requestの承認や変更リクエストをするレビューをサブミットできます。 Organization の所有者とリポジトリ管理者は、pull request レビューまたは要求の変更を承認できるユーザーを制限できます。 詳細については、「OrganizationでのPull Requestのレビューの管理」および「リポジトリでのプルリクエストのレビューの管理」を参照してください。

リポジトリオーナーとコラボレーターは、特定の人物にプルリクエストのレビューをリクエストできます。 また、Organization メンバーは、リポジトリの読み取りアクセス権を持つ Team にプルリクエストのレビューをリクエストできます。 詳しくは、「Pull Request レビューをリクエストする」を参照してください。 チーム メンバーのサブセットを指定して、チーム全体に代わって自動的に割り当てることができます。 詳しくは、「Teamのコードレビュー設定の管理」を参照してください。

レビューにより、提案された変更についての議論がなされ、その変更がリポジトリのコントリビューションのガイドラインやその他の品質標準を満たすことを保証しやすくなります。 コードの特定の種類や領域に対して、どの個人や Team をオーナーとするかを、CODEOWNERS ファイルで定義できます。 プルリクエストが、定義されたオーナーを持っているコードを変更するものである場合、オーナーである個人あるいはTeam がレビューを担当するよう、自動的にリクエストされます。 詳しくは、「コードオーナーについて」を参照してください。

pull requests レビューの要求と提供の概要については、pull requests のレビュー GitHub Skills コースを参照してください。

レビューする必要がある pull request のアラームのリマインダーをスケジュールできます。 詳細については、「Team のスケジュールされたリマインダーを管理する」を参照してください。

レビューには 3 つのステータスがあります:

  • コメント: 変更を明示的に承認したり、追加の変更を要求したりせずに、一般的なフィードバックを送信します。
  • 承認: フィードバックを送信し、pull request で提案された変更のマージを承認します。
  • 変更の要求: pull request をマージする前に対処する必要があるフィードバックを送信します。

ヒント:

  • リクエストの変更オプションは純粋に情報提供を目的としており、ルールセットまたはクラシック ブランチ保護ルールが [pull request の要求] オプションで構成されていない限り、マージの防げにはなりません。 ルールが構成されており、リポジトリへの admin、owner、または write アクセス権を持つコラボレーターが変更を要求するレビューを送信した場合、同じコラボレーターが pull request の変更を承認する別のレビューを送信するまで、pull request をマージすることはできません。
  • リポジトリのオーナーと管理者は、プルリクエストが承認レビューを受けていなかったり、あるいは変更をリクエストしたレビュー担当者がOrganizationを離れていたりアクセスできなくなっている場合でも、プルリクエストをマージできます。
  • 必須レビューと古いレビューの棄却がどちらも有効化されており、承認済みのプルリクエストのブランチにコードを変更するコミットがプッシュされた場合、その承認は却下されます。 そのプルリクエストは、再度レビューされ承認されるまではマージできません。
  • 同じコミットを指す複数のオープンされたプルリクエストがあり、それぞれがheadブランチを持つ場合、いずれかがペンディングあるいは拒否されたレビューを持っているなら、それらはマージできません。
  • 書き込みまたは管理者のアクセス許可を持つ個人からのレビューの承認を必須としているリポジトリの場合、これらのアクセス許可を持つ個人からの承認には緑色のチェック マークが表示され、これらのアクセス許可を持たない個人からの承認には灰色のチェック マークが表示されます。 灰色のチェック マークが付いた承認は、pull request をマージできるかどうかに影響しません。
  • Pull Requestの作者は、自分自身のPull Requestを承認することはできません。

プルリクエストが受けたすべてのレビューは、Conversationタイムラインで見ることができ、リポジトリオーナー及びコラボレーターによるレビューは、プルリクエストのマージボックスで見ることができます。

pull request のマージ ボックスのスクリーンショット。 要求された変更を含む Octocat によるレビューが一覧表示されています。

ヒント: 検索修飾子 review-requested:[USERNAME] または team-review-requested:[TEAMNAME] が使用された、自分または自分がメンバーであるチームが確認を求められているプルリクエストを探すことができます。 詳しくは、「Issue およびプルリクエストを検索する」を参照してください。

会話を解決する

プルリクエストをオープンしたり、プルリクエストがオープンされたリポジトリへの書き込みアクセス権を持っていたりすれば、プルリクエスト中の会話を解決できます。

[変更されたファイル] タブの会話が完了したことを示すには、 [会話の解決] をクリックします。

会話全体が畳まれ、解決のマークが付きます。これで、まだ対応が必要な会話を見つけやすくなります。

コメントの示唆がプルリクエストの範囲を超えているなら、そのコメントへのフィードバックやリンクを追跡する新しいIssueをオープンできます。 詳しくは、「Issue の作成」を参照してください。

会話の発見とアクセス

[変更されたファイル] タブの上部に表示される [会話] メニューを使用すると、pull request 内のすべての会話を検出して移動できます。

このビューから、未解決の会話、解決済みの会話、古くなった会話を見分けることができます。 これによって、会話を見つけて解決することが容易になります。

pull request の [変更されたファイル] タブの [会話] メニューのスクリーンショット。

レビューを再リクエストする

たとえばPull Requestに相当の変更を加えた後に、レビューを再度リクエストできます。 レビュー担当者からの新しいレビューをリクエストするには、 [会話] タブのサイドバーで、 アイコンをクリックします。

必須のレビュー

リポジトリ管理者または "リポジトリ ルールの編集" アクセス許可を持つカスタム ロールは、保護されたブランチに他のユーザーがすべての pull request をマージする前に、特定の数の承認レビューがそれらの pull request に届くことを必須にすることができます。 リポジトリに書き込み権限を持っている人か、指定されたコードオーナーからの承認レビューを必須とすることができます。 詳細については、「保護されたブランチについて」を参照してください。

ヒント: 必要に応じて、リポジトリへの 管理者 または 書き込み アクセス権を持つユーザーは、pull request レビューを無視できます。 詳しくは、「プルリクエストレビューの却下」を参照してください。

参考資料