Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-10-12. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

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

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

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

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

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

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

凝固メント付きの変更をリクエストするレビューのヘッダ

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

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

レビューステータスの画像

ヒント:

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

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

マージボックス中のレビューの画像

ヒント: 検索修飾子 review-requested:[USERNAME] または team-review-requested:[TEAMNAME] が使用された、自分または自分がメンバーであるチー� が確認を求められているプルリクエストを探すことができます。 詳細については、「Searching issues and pull requests」 (問題とプルリクエストの検索) を参照してく� さい。

Resolving conversations

You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.

To indicate that a conversation on the Files changed tab is complete, click Resolve conversation.

Pull request conversation with Resolve conversation button

The entire conversation will be collapsed and marked as resolved, making it easier to find conversations that still need to be addressed.

Resolved conversation

If the suggestion in a comment is out of your pull request's scope, you can open a new issue that tracks the feedback and links back to the original comment. For more information, see "Opening an issue from a comment."

Discovering and navigating conversations

You can discover and navigate to all the conversations in your pull request using the Conversations menu that's shown at the top of the Files Changed tab.

From this view, you can see which conversations are unresolved, resolved, and outdated. This makes it easy to discover and resolve conversations.

Showing the conversations menu

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

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

必� �のレビュー

リポジトリ管理者はすべてのPull Requestに対し、保護されたブランチにPull Requestを誰かがマージできるようになる前に受けなければならない承認レビューの数を指定できます。 リポジトリに書き込み権限を持っている人か、指定されたコードオーナーからの承認レビューを必� �とすることができます。詳細については、「保護されたブランチについて」を参照してく� さい。

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

参考資料