pull request のレビュー

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

pull request (PR) を作成し、必要な/オプションのレビュー担当者を指定すると、Azure Repos により、PR がレビューの準備を完了していることがレビュー担当者に通知されます。 すべての必須のレビュー担当者は、変更をターゲット ブランチにマージする前に、PR の変更を承認する必要があります。 main ブランチなどの重要なブランチを変更する PR の場合、チームはレビュー担当者を指定するか、最小数のレビュー担当者を必要とするブランチ ポリシーを作成する必要がある場合があります。 ブランチ ポリシーでオプションのレビュー担当者を PR に追加する場合は、それらを保持、要求、または削除できます。 ブランチ ポリシーで必須のレビュー担当者を PR に追加する場合は、それらをオプションにしたり、削除したりすることはできません。 ブランチ ポリシーを使用したレビュー担当者の割り当ての詳細については、「コード レビュー担当者を自動的に含める」を参照してください。

PR をレビューする場合は、正確でわかりやすい建設的なフィードバックを提供するようにしてください。 レビューのフィードバックについては、pull request のフィードバックに関するページを参照してください。 この記事では、Azure DevOps で pull request をレビューする方法について説明されています。

Azure DevOps の PR は、ブラウザーを使用して Web ポータルでのみレビューできます。

この記事では、次の方法について説明します。

• 変更の確認
• コメントを使用する
• ファイルを編集する
• レビュー済みファイルを追跡する
• PR の変更に投票する
• PR を完了する

前提条件

• Repos を Azure DevOps プロジェクト設定で有効にする必要があります。 Repos ハブと関連ページが表示されない場合は、Azure DevOps サービスのオンとオフの切り替えに関するページを参照して Repos を再度有効にしてください。

• PR をレビューするには、PR が含まれている Azure DevOps プロジェクトのメンバーであり、Basic 以上のアクセス レベルを持っている必要があります。

  • プロジェクトがない場合は、作成するか、無料でサインアップします。

  • プロジェクト メンバーでない場合は、追加してもらいます。

  注意

  パブリック プロジェクトの場合、利害関係者アクセス権を付与されたユーザーは、Azure Repos へのフル アクセス権があります。

• アクセス許可とアクセス権の詳細については、「既定の Git リポジトリとブランチのアクセス許可」および「アクセス レベルについて」を参照してください。

PR は、Azure DevOps コマンド ライン インターフェイス (CLI) を使用して、Azure DevOps Services で管理できます。 Azure DevOps CLI は、Azure CLI と AzureDevOps 拡張機能をインストールする場合に使用できます。 PR を管理する CLI コマンドの一覧については、az repos pr コマンドを参照してください。

変更の確認

pull request を使用すると、指定されたレビュー担当者は、提案された変更がリポジトリのターゲット ブランチに適用される前に、それらを調査、議論、投票できます。 別のブランチで同じファイルを使用して開発を行う場合は、競合する変更が発生する可能性があることに注意してください。 その場合は、それらの競合を慎重に分析して解決する必要があります。 これを行うには、ソース、ターゲット、または両方のブランチからの変更を正しく適用するために、ファイルを手動で編集する必要がある場合があります。 ソースまたはターゲットからすべての変更を適用 (1 回のボタン クリックで実行できます) することは最適ではない可能性があり、必要な変更の一部が失われる可能性があります。 これは、ADO ツールを使用して行うことができます。または、開発ツール (Visual Studio など) を使用すると、より便利です。

詳細については、「マージの競合を解決する」を参照してください。

次の手順では、Azure Repos の PR のレビュー担当者が PR をナビゲートして、提案された変更を理解する方法について説明します。

1. Web ブラウザーから、Azure DevOps 組織のチーム プロジェクトを開きます。 [Repos] > [Pull requests] を選択して、PR を一覧表示します。 新しく開いた PR は、既定で [概要] タブになります。

2. PR の [概要] タブには、タイトル、説明、レビュー担当者、リンクされた作業項目、履歴、状態、コメントが表示されます。 PR の説明を読んで、提案された変更を確認します。 コメントを表示して、他のレビュー担当者が提起した問題を理解します。

   注意

   各ファイルでは、変更の数が推定され、名前の横に [+] 記号または [rename, edit] (名前変更、編集) ラベルでマークされます。 ファイルに 50% を超える変更がある場合は、"名前変更された" と見なされます。これは Git リポジトリの既定のしきい値であり、変更できません。

   

3. [ファイル] タブを選択して、PR のソース ブランチ内のすべてのコンテンツ変更をレビューします。 初期ビューには、すべてのファイル変更の概要ビューが表示されます。 ファイルの横にある [View] (表示) ボタンを選択すると、そのファイルの変更のみが表示されます。 ファイルが変更された場合は、[View] (表示) ボタンで差分ビューが開きます。 ファイルが追加または削除された場合は、[View] (表示) ボタンでコンテンツ ウィンドウが開きます。

   

   注意

   パフォーマンス上の理由から、概要ビューには、0.5 MB を超えるファイルの変更は表示されません。

4. ファイルの差分ビューでは、横並びまたはインライン差分レイアウトを選択できます。

   

   ヒント

   5 MB を超える "1 つ" のファイルの場合、差分ビューには切り捨てられたファイルの内容が表示されます。 完全なコンテンツを差分表示するには、ローカル差分ツールを使用して、このようなファイルをダウンロードしてレビューします。

   左側のファイル ツリーを使用して別のファイルを表示するか、ファイル ツリーのルートを選択してすべてのファイル変更の概要ビューを表示します。

5. ソース ブランチへの特定のプッシュによって導入された変更セットを確認するには、変更ドロップダウン リストから 1 つ以上の変更セットを選択します。 1 つ以上の変更セットを選択すると、差分ビューが更新され、選択した変更セットからの変更のみが表示されます。 この機能は、前回のレビュー以降に変更が PR にプッシュされ、新しい変更を確認するだけの場合に役立ちます。 変更ドロップダウン リストでは、各プッシュ操作の最後のコミットからのコミット メッセージによって各変更セットの名前が付けられます。

   

   ヒント

   変更ドロップダウン リストから複数の変更セットを選択するときは、Shift キーを押したままにします。

6. [更新] タブを選択して、プッシュされたすべての変更セットを表示して、ソース ブランチの変更を見逃していないことを確認します。 変更セットには番号が付き、最新の変更セットが一覧の上部に表示されます。 各変更セットには、プッシュ操作でプッシュされたコミットが表示されます。 強制プッシュされた変更セットでは変更セット履歴は上書きされず、他の変更セットと同じように変更セットの一覧に表示されます。

   

7. [コミット] タブを選択すると、ターゲット ブランチから分岐した後のソース ブランチのコミット履歴が表示されます。 PR の作成者が別のコミット履歴を強制プッシュすると、[コミット] タブのコミット履歴が上書きされるため、[コミット] タブに表示されるコミットが [更新] タブに表示されるコミットと異なる場合があります。

   

ファイルのレビュー

PR の [ファイル] タブを選択して、pull request のターゲット ブランチの横にあるソース ブランチに対して行われた実際の変更を表示します。

注意

Azure DevOps の pull request と Azure DevOps のブランチの比較で変更に違いがあるのは、比較方法が異なるためです。

git diff コマンドには、2 つのドット (git diff A..B) と 3 つのドット (git diff A...B) の 2 つの比較方法があります。 既定では、pull request では 3 つのドットの diff が表示され、ブランチの比較では 2 つのドットの diff が表示されます。

次に例を示します。

      C---D---E branch
     /
A---B---F---G   master

Pull Requests: git diff branch...master は C、D、E コミットのみを生成します。 ブランチの比較: git diff branch..master では C、D、E、F、G のコミットが生成されます。

詳細については、3 つのドットと 2 つのドットの git diff の比較と git diff に関するページを参照してください

注意

"選択した 1 つのファイル" の差を表示する場合、ファイル サイズの制限は 5 MB です。 5 MB を超えるファイルを差分表示するには、ファイルをダウンロードし、ローカル差分ツールを使用して表示できます。 ファイルのコレクションの差を表示する場合、パフォーマンス上の理由から、各ファイルのサイズ制限は 0.5 MB です。

更新のレビュー

[All updates] (すべての更新) ドロップダウン リストから、以前のバージョンのコードをレビューします。

ブランチが更新されるたびに、PR の一覧と [更新] タブに新しいバージョンが追加されます。 別の更新を選択すると、差分ビューが更新され、PR の各バージョンのファイル間の差が表示されます。

前回のレビュー以降に行われた変更をステップ実行することで、PR から離れた後でも PR の更新に追いつくことができます。

[更新] タブで作成者からの変更の一覧を参照します。

[コミット] タブで、ブランチへのコミットで行われた変更を表示して選択します。

コメントを使用する

PR の作成者とレビュー担当者は、PR コメントを追加して返信することで、相互にコミュニケーションを取ることができます。 PR をレビューするときは、コメントを使用します。提案された変更に関する問題を指摘し、変更を提案して、前のコメントに返信します。 正確でわかりやすい建設的なフィードバックを目指してください。 @username を使用して受信者を直接指定します。 #workitemID を使用して作業項目を参照し、!pullrequestID を使用して他の PR を参照します。 PR の作成者は、文書化の目的で自分自身にコメントを作成することがあります。

コメントでフィードバックを送信する

フィードバックがファイル内の特定の行または行範囲を対象としている場合は、ファイル内のその場所にコメントを追加します。

1. PR の [ファイル] タブで、コメントする行にカーソルを合わせ、コメント ボタン を選択してインライン コメント ボックスを開きます。 複数の行を選択し、それらの行にカーソルを合わせると表示されるコメント ボタンを選択することもできます。

   

2. コメント ボックスにコメントを入力し、[コメント] を選択します。

   

フィードバックがファイル全体を対象としている場合は、ファイルのオプション メニューから [コメントの追加] を選択して、ファイル レベルのコメントを追加します。

特定のファイルに関連しない一般的なフィードバックを提供するには、[概要] タブにコメントを追加します。

PR のレビュー担当者も、コメントを使用して、次のセクションで説明するように、特定のファイル行への変更を提案することができます。

コメントで変更を提案する

コメントを使用して、ファイル内の 1 行以上の置換テキストを提案できます。

1. PR の [ファイル] タブで、コメントする行にカーソルを合わせ、コメント ボタン を選択してインライン コメント ボックスを開きます。 複数の行を選択し、それらの行にカーソルを合わせると表示されるコメント ボタンを選択することもできます。 受け入れられた場合、提案されたコンテンツは、コメントが追加された行または複数行に置き換えられます。

   

2. コメント ボックスの下にある電球アイコンを選択して、フェンスされたコード ブロック内のコメント ボックスで提案する変更を作成し、[コメント] を選択します。 横並びの差分ビューの元のコード (左側) にコメントを追加しても、電球アイコンは表示されません。

   

PR の作成者は、次のようにして提案を受け入れます。

1. [変更の適用] を選択して、コミットの準備状況の変更をステージングします。

   

2. [すべての変更をコミットする] を選択して、ステージングされたすべての変更をコミットします。 PR の作成者は、[変更を元に戻す] を選択して、提案のステージングを解除できます。

   

コメントを編集または削除する

コメントにカーソルを合わせ、[編集] または [削除] の各アイコンを選択すると、コメントを編集または削除できます。

コメントに "いいね!" を付ける

PR の作成者とレビュー担当者は、コメントにカーソルを合わせ、サムズアップ アイコンを選択することで、自分や他のユーザーのコメントに "いいね!" を付けることができます。

"いいね!" が付いたコメントには、色が付いたサムズアップ アイコンと "いいね!" の数が表示されます。 サムズアップ アイコンの上にカーソルを合わせると、コメントに "いいね!" を付けたユーザーの一覧が表示されます。

コメントに返信する

PR の作成者はコメントに返信して、フィードバックや提案にどのように対処しているかをレビュー担当者に知らせる必要があります。

1. コメントに返信するには、[Write a reply] (応答をご記述ください) フィールドに応答を入力します。 @username を使用して受信者を直接指定します。 #workitemID を使用して作業項目を参照し、!pullrequestID を使用して他の PR を参照します。

   

2. 応答を入力した後、自分の応答が最終的な場合は [応答して解決]を選択します。 そうでない場合は、[Reply] (返信) を選択します。

   

   [応答して解決] を選択すると、コメントの状態が [解決済み] に変わります。 PR の作成者も、次のセクションで説明するように、コメントの状態を直接変更することができます。

コメントの状態を変更する

新しいコメントは、最初は [アクティブ] な状態になっています。これは PR の作成者によって、レビュー担当者のフィードバックや提案にどのように対処したかを示すために、レビュー プロセス中に更新されます。 PR の作成者は、状態ドロップダウン リストからコメントの状態を選択できます。

• [アクティブ]: 新しいコメントの既定の状態です。

• [保留中]: このコメントの問題はレビュー中であり、他の作業を待機しています。

• [解決済み]: このコメントの問題は対処済みです。

• [修正しない]: このコメントの問題は把握されていますが、修正されません。

• [終了]: このコメントのディスカッションは終了しています。

PR の作成者とレビュー担当者は、次のセクションで説明するように、コメントの状態をフィルター処理することで PR の進行状況を追跡できます。

コメントをフィルター処理する

コメント フィルター ドロップダウン リストからフィルター オプションを選択すると、[概要] タブに表示するコメントまたは更新を選択できます。 たとえば、PR を最後に開いた後の新しいコメントと更新を表示するには、[What's new] (最新情報) フィルター オプションを選択します。 各フィルター オプションには、そのカテゴリの項目の数が表示されます。

ファイルを編集する

利便性のため、PR の作成者は Azure Repos で直接ファイルを編集できます。 たとえば、レビュー担当者によって提案されたコード変更を受け入れ、他の場所で同様の変更を行いたいとします。

1. [Repos] > [Files] (ファイル) を選択し、PR のソース ブランチを選択し、ファイルを選択して、[編集] を選択します。

   

2. エディターで変更を行い、[コミット] を選択して [コミット] ダイアログを開きます。

   

3. コミット ダイアログで、必要に応じてコミット メッセージを編集し、コミット を選択して変更をコミットし、PR にプッシュします。

   

レビュー済みファイルを追跡する

PR のレビュー担当者は、ファイル オプション メニューから [レビュー済みとしてマーク] を選択するか、ファイルまたはフォルダーの横にあるチェック ボックスをオンにすることで、レビュー済みファイルを引き続き追跡できます。

PR の変更に投票する

ブラウザー

PR のレビュー担当者は、投票ドロップダウン リストから投票オプションを選択することで、PR に投票できます。 PR ページのレビュー担当者アイコンには、投票を示す情報が表示されます。

投票オプションは次のとおりです。

• [承認]: PR で提案された変更を承認します。 このオプションは単なる投票であり、PR を承認するものではありません。

• [承認と提案]: PR で提案された変更を承認し、改善のためのオプションの提案を行います。 このオプションは単なる投票であり、PR を承認するものではありません。

• [作成者を待つ]: 作成者にレビュー担当者のコメントを確認するよう求めます。 PR 作成者は、PR 作成者がコメントに対処した後、レビュー担当者に知らせて、コードを再度レビューしてもらう必要があります。 必須のレビュー担当者がこの投票オプションを設定すると、投票によって PR の承認がブロックされます。

• [却下する]: 変更が受け入れられないことを示します。 このオプションを選択する場合は、理由を説明するコメントを追加します。 必須のレビュー担当者がこの投票オプションを設定すると、投票によって PR の承認がブロックされます。

• フィードバックのリセット: 投票をクリアします。 投票がない場合でも、PR の完了が妨げられることはありません。

Azure DevOps CLI

PR の承認の可否を投票するには、az repos pr set-vote コマンドを使用します。

az repos pr set-vote --id
                     --vote {approve, approve-with-suggestions, reject, reset, wait-for-author}
                     [--detect {false, true}]
                     [--org]
                     [--subscription]

パラメーター

パラメーター	必須	Description
--id	はい	Pull request ID
--vote	はい	pull request の新しい投票値 (受け入れ可能な値: approve、approve-with-suggestions、reject、reset、または wait-for-author)
--detect	いいえ	組織の自動検出 (受け入れ可能な値: false、true)
--organization	はい (既定の組織が設定されておらず、Git 構成ファイルで組織が指定されていない場合)	Azure DevOps 組織の URL。または、az devops configure -d organization=<organization URL> を使用して既定の組織を設定します
--subscription	いいえ	Azure サブスクリプションの名前または ID。または、az account set -s <name or ID> を使用して既定のサブスクリプションを設定します

例

次のコマンドは、PR #21 の承認に投票します。 コマンドはテーブルを返します。

az repos pr set-vote --id 21 --vote approve --output table

Name            Email                ID                                    Vote      Required
--------------  ------------------- -------------------------------------  --------  ----------
Jamal Hartnett  jamalh@fabrikam.com  00000000-0000-0000-0000-000000000000  Approved  False

次のコマンドを実行すると、投票が削除されます。 コマンドはテーブルを返します。

az repos pr set-vote --id 21 --vote reset --output table

Name            Email                ID                                    Vote      Required
--------------  ------------------- -------------------------------------  --------  ----------
Jamal Hartnett  jamalh@fabrikam.com  00000000-0000-0000-0000-000000000000            False

PR を完了する

PR の作成者は、PR 解決オプションを選択できます。

• [完]了: すべての必須のレビュー担当者が承認し、必要なすべてのブランチ ポリシーが満たされている場合、PR を今すぐ完了します。

• [オートコンプリートの設定]: すべての必須のレビュー担当者が承認し、必要なすべてのブランチ ポリシーが満たされたときに、PR をオートコンプリートします。

• [ドラフトとしてマーク]: PR をドラフトの状態に設定して、レビューの準備ができていないことを示します。 ドラフト PR の場合は、[公開する] を選択してドラフトの状態を削除し、レビュー準備完了とマークできます。

• [Abandon] (破棄): PR を閉じます。 破棄された PR の場合は、[Reactivate] (再アクティブ化) を選択して復元できます。

PR の完了の詳細については、pull request の完了に関するページを参照してください。

次のステップ

pull request を完了する

関連記事

• pull request 更新通知
• pull request とアクセス許可について