Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
ヒント
AI を使用して、Azure DevOps タスクに役立てることができます。 作業を開始するには、 Azure DevOps MCP Server で AI サポートを有効にする 方法に関するページを参照してください。
pull 要求 (PR) を作成し、必須およびオプションのレビュー担当者を指定すると、Azure Reposは PR がレビューの準備ができていることをレビュー担当者に通知します。 すべての必須のレビュー担当者は、変更をターゲット ブランチにマージする前に、PR の変更を承認する必要があります。
mainなどの重要なブランチを変更する PR の場合、チームには、校閲者を指定したり、最小限の校閲者を必要とするブランチ ポリシーが存在する場合があります。 ブランチ ポリシーでオプションのレビュー担当者を PR に追加する場合は、それらを保持、要求、または削除できます。 ブランチ ポリシーで必須のレビュー担当者を PR に追加する場合は、それらをオプションにしたり、削除したりすることはできません。 ブランチ ポリシーを使用したレビュー担当者の割り当ての詳細については、「コード レビュー担当者を自動的に含める」を参照してください。
PR をレビューするときは、正確でわかりやすい建設的なフィードバックを提供します。 詳細については、「プル リクエストのフィードバック」を参照してください。
Azure DevOps の PR は、ブラウザーを使用して Web ポータルでのみレビューできます。
前提条件
| カテゴリ | 必要条件 |
|---|---|
| プロジェクト | Azure DevOps プロジェクト。 プロジェクトがない場合は、作成するか、無料でサインアップします。 |
| サービス | Reposプロジェクトで有効になります。 Repos ハブが表示されない場合は、「Azure DevOps サービスをオンまたはオフにするを参照してください。 |
| アクセス レベル | 少なくともBasicアクセス。 パブリック プロジェクトの場合、Stakeholder アクセス権を持つユーザーは、Azure Repos へのフル アクセス権を持ちます。 |
| アクセス許可 | PR を含む Azure DevOps プロジェクトのメンバーであること。 プロジェクト メンバーでない場合は、追加してもらうようにしてください。 詳細については、「既定の Git リポジトリとブランチのアクセス許可」および「アクセス レベルについて」を参照してください。 |
| カテゴリ | 必要条件 |
|---|---|
| サービス | Reposプロジェクトで有効になります。 Repos ハブが表示されない場合は、「Azure DevOps サービスをオンまたはオフにするを参照してください。 |
| アクセス レベル | 少なくともBasicアクセス。 |
| アクセス許可 | PR を含む Azure DevOps プロジェクトのメンバーであること。 プロジェクト メンバーでない場合は、追加してもらうようにしてください。 詳細については、「既定の Git リポジトリとブランチのアクセス許可」および「アクセス レベルについて」を参照してください。 |
PR は、Azure DevOps コマンド ライン インターフェイス (CLI) を使用して、Azure DevOps Services で管理できます。 Azure DevOps CLI は、Azure CLI と AzureDevOps 拡張機能をインストールする場合に使用できます。 PR を管理する CLI コマンドの一覧については、az repos pr コマンドを参照してください。
変更の確認
Pull requests を使用すると、指定されたレビュー担当者は、変更がターゲット ブランチにマージされる前に、提案された変更を調査、議論、投票できます。 ソースブランチとターゲットブランチの両方で同じファイルが変更されると、マージの競合が発生する可能性があります。 競合を慎重に分析し、ファイルを手動で編集して、各ブランチから適切な変更を適用します。 ソースのみ、または 1 回のクリックでターゲットからのみすべての変更を行うと、必要な変更が失われる可能性があります。 競合は、Azure DevOpsまたは Visual Studio などの開発ツールで解決できます。
詳細については、「 マージの競合を解決する」を参照してください。
Copilot コード レビューを要求する
GitHub Copilotに、人間のレビュー担当者と共に pull request をレビューするように依頼できます。 Copilot変更されたコードに直接コメントや提案を投稿するので、人間のレビュー担当者がサインオフする前に一般的な問題に対処できます。
レビューを要求するには、pull request を開き、
この機能は限定パブリック プレビュー段階であり、サインアップが必要です。 セットアップ、課金、および制限については、プル リクエスト向け Copilot code review の使い始め方を参照してください。
人間の校閲者として変更を確認する
次の手順では、Azure Repos の PR のレビュー担当者が PR をナビゲートして、提案された変更を理解する方法について説明します。
Web ブラウザーから、Azure DevOps 組織のチーム プロジェクトを開きます。 [Repos>Pull requests を選択して PR を一覧表示します。 新しく開いた PR は、既定で [概要] タブになります。
PR の [ 概要 ] タブには、タイトル、説明、レビュー担当者、リンクされた作業項目、履歴、状態、コメントが表示されます。 PR の説明を読んで、提案された変更を確認します。 コメントを表示して、他のレビュー担当者が提起した問題を理解します。
注意
各ファイルには、変更の種類を示すために、名前の横に "+" 記号または "名前の変更、編集" ラベルが付けられます。 ファイルに 50% を超える変更がある場合、Git では名前が 変更されたと見なされます。 このしきい値は Git リポジトリの既定値であり、変更することはできません。
[ファイル] タブを選択して、PR のソース ブランチ内のすべてのコンテンツ変更をレビューします。 初期ビューには、すべてのファイル変更の概要ビューが表示されます。 ファイルの横にある [View] (表示) ボタンを選択すると、そのファイルの変更のみが表示されます。 ファイルが変更された場合は、[View] (表示) ボタンで差分ビューが開きます。 ファイルが追加または削除された場合は、[View] (表示) ボタンでコンテンツ ウィンドウが開きます。
注意
パフォーマンス上の理由から、概要ビューには、0.5 MB を超えるファイルの変更は表示されません。
ファイルの差分ビューでは、横並びまたはインライン差分レイアウトを選択できます。
ヒント
5 MB を超える単一のファイルの場合、差分ビューにはトランクされたファイルの内容が表示されます。 完全なコンテンツの差分ビューについては、ローカル差分ツールを使用して、そのようなファイルをダウンロードして確認します。
左側のファイル ツリーを使用して別のファイルを表示するか、ファイル ツリーのルートを選択してすべてのファイル変更の概要ビューを表示します。
ソース ブランチへの特定のプッシュによって導入された変更セットを確認するには、変更ドロップダウン リストから 1 つ以上の変更セットを選択します。 1 つ以上の変更セットを選択すると、差分ビューが更新され、選択した変更セットからの変更のみが表示されます。 この機能は、前回のレビュー以降に変更が PR にプッシュされ、新しい変更のみを表示する場合に便利です。 変更ドロップダウン リストでは、各プッシュ操作の最後のコミットからのコミット メッセージによって各変更セットの名前が付けられます。
ヒント
変更ドロップダウン リストから複数の変更セットを選択するときは、Shift キーを押したままにします。
[ 更新] タブを選択して、プッシュされたすべての変更セットを表示し、ソースブランチの変更を見逃していないことを確認します。 変更セットには番号が付き、最新の変更セットが一覧の上部に表示されます。 各変更セットには、プッシュ操作でプッシュされたコミットが表示されます。 強制プッシュされた変更セットは変更セット履歴を上書きせず、他の変更セットと同様に変更セットの一覧に表示されます。
[コミット] タブを選択すると、ターゲット ブランチから分岐した後のソース ブランチのコミット履歴が表示されます。 PR 作成者が別のコミット履歴を強制的にプッシュすると、[ コミット ] タブのコミット履歴が上書きされるため、[ コミット ] タブに表示されるコミットが [ 更新 ] タブに表示されるコミットと異なる場合があります。
コメントを使用する
PR の作成者とレビュー担当者は、PR コメントを追加して返信することで、相互にコミュニケーションを取ることができます。 PR を確認するときは、コメントを使用して、提案された変更に関する問題を指摘し、 変更を提案し、以前のコメントに応答します。 正確でわかりやすい建設的なフィードバックを目指してください。
@username を使用して受信者を直接指定します。
#workitemID を使用して作業項目を参照し、!pullrequestID を使用して他の PR を参照します。 PR の作成者は、文書化の目的で自分自身にコメントを作成することがあります。
コメントでフィードバックを送信する
フィードバックがファイル内の特定の行または行範囲を対象としている場合は、ファイル内のその場所にコメントを追加します。
PR の [ファイル] タブで、コメントする行にカーソルを合わせ、コメント ボタン
を選択してインライン コメント ボックスを開きます。 複数の行を選択し、それらの行にカーソルを合わせると表示されるコメント ボタンを選択することもできます。コメント ボックスにコメントを入力し、[コメント] を選択します。
フィードバックがファイル全体を対象としている場合は、ファイルのオプション メニューから [コメントの追加] を選択して、ファイル レベルのコメントを追加します。
特定のファイルに関連しない一般的なフィードバックを提供するには、[概要] タブにコメントを追加します。
PR のレビュー担当者も、コメントを使用して、次のセクションで説明するように、特定のファイル行への変更を提案することができます。
コメントで変更を提案する
コメントを使用して、ファイル内の 1 行以上の置換テキストを提案します。
PR の [ファイル] タブで、コメントする行にカーソルを合わせ、コメント ボタン
を選択してインライン コメント ボックスを開きます。 複数の行を選択し、それらの行にカーソルを合わせると表示されるコメント ボタンを選択することもできます。 受け入れられた場合、コメントが追加された行が、提案されたコンテンツによって置き換えられます。コメント ボックスの下にある電球アイコンを選択して、フェンスされたコード ブロック内のコメント ボックスで提案する変更を作成し、[コメント] を選択します。 サイド バイ サイドの差分ビューの元のコード (左側) にコメントを追加すると、電球アイコンは表示されません。
PR 作成者は、提案を受け入れるには次のことを行います。
[変更の適用] を選択して、コミットの準備状況の変更をステージングします。
[すべての変更をコミットする] を選択して、ステージングされたすべての変更をコミットします。 PR の作成者は、[変更を元に戻す] を選択して、提案のステージングを解除できます。
コメントを編集または削除する
コメントの上にマウス ポインターを置き、編集または削除アイコンを選択して、コメントを 編集 または 削除 します。
コメントに "いいね!" を付ける
PR の作成者とレビュー担当者は、コメントにカーソルを合わせ、サムズアップ アイコンを選択することで、自分や他のユーザーのコメントに "いいね!" を付けることができます。
いいね!を含むコメントには、入力されたサムアップ アイコンといいねの数が表示されます。 サムズアップ アイコンの上にカーソルを合わせると、コメントに "いいね!" を付けたユーザーの一覧が表示されます。
コメントに返信する
PR の作成者はコメントに返信して、フィードバックや提案にどのように対処しているかをレビュー担当者に知らせる必要があります。
コメントに返信するには、[Write a reply] (応答をご記述ください) フィールドに応答を入力します。
@usernameを使用して受信者を直接指定します。#workitemIDを使用して作業項目を参照し、!pullrequestIDを使用して他の PR を参照します。
応答を入力した後、自分の応答が最終的な場合は [応答して解決]を選択します。 そうでない場合は、[Reply] (返信) を選択します。
[返信して解決] を選択すると、コメントの状態が [解決済み] に変わります。 PR の作成者も、次のセクションで説明するように、コメントの状態を直接変更することができます。
コメントの状態を変更する
新しいコメントは 、アクティブ な状態から始まります。 PR 作成者は、レビュー プロセス中に状態を更新して、レビュー担当者のフィードバックと提案にどのように対処したかを示します。 PR の作成者は、状態ドロップダウン リストからコメントの状態を選択できます。
- アクティブ: 新しいコメントの既定の状態。
- 保留中:このコメントの問題はレビュー中であり、他の何かを待っています。
- 解決済み: このコメントの問題に対処しました。
- 修正されません:このコメントの問題は記載されていますが、修正されません。
- 終了: このコメントのディスカッションは終了しています。
PR の作成者とレビュー担当者は、次のセクションで説明するように、コメントの状態をフィルター処理することで PR の進行状況を追跡できます。
コメントをフィルター処理する
コメント フィルター ドロップダウン リストからフィルター オプションを選択すると、[概要] タブに表示するコメントまたは更新を選択できます。 たとえば、PR を最後に開いた後の新しいコメントと更新を表示するには、[What's new] (最新情報) フィルター オプションを選択します。 各フィルター オプションには、そのカテゴリの項目の数が表示されます。
ファイルを編集する
利便性のため、PR の作成者は Azure Repos で直接ファイルを編集できます。 たとえば、校閲者の提案されたコード変更を受け入れ、他の場所で同様の変更を行う場合があります。
Repos > Files を選択し、PR ソース ブランチを選択してファイルを選択し、Edit を選択します。
エディターで変更を行い、[コミット] を選択して [コミット] ダイアログを開きます。
コミット ダイアログで、必要に応じてコミット メッセージを編集し、コミット を選択して変更をコミットし、PR にプッシュします。
レビュー済みファイルを追跡する
PR のレビュー担当者は、ファイル オプション メニューから [レビュー済みとしてマーク] を選択するか、ファイルまたはフォルダーの横にあるチェック ボックスをオンにすることで、レビュー済みファイルを引き続き追跡できます。
PR の変更に投票する
PR のレビュー担当者は、投票ドロップダウン リストから投票オプションを選択することで、PR に投票できます。 PR ページの校閲者アイコンは投票を示します。
投票オプションは次のとおりです。
- 承認: PR で提案された変更を承認します。 このオプションは投票であり、PR を完了しません。
- 提案を使用して承認する: 提案された変更を承認し、改善のためのオプションの提案を行います。 このオプションは投票であり、PR を完了しません。
- 作成者を待つ: 作成者にレビュー担当者のコメントを確認するよう求めます。 PR 作成者は、レビュー担当者に、コメントに対処した後にコードを再レビューすることを知らせる必要があります。 必須の校閲者がこのオプションを設定すると、投票によって PR 承認がブロックされます。
- 拒否: 変更が受け入れられないことを示します。 このオプションを選択する場合は、理由を説明するコメントを追加します。 必須の校閲者がこのオプションを設定すると、投票によって PR 承認がブロックされます。
- フィードバックをリセットする: 投票をクリアします。 投票がない場合でも、PR の完了が妨げられることはありません。
PR を完了する
PR の作成者は、PR 解決オプションを選択できます。
- 完了: 必要なすべての校閲者が承認し、必要なすべてのブランチ ポリシーが満たされている場合は、今すぐ PR を完了します。
- オートコンプリートを設定する: 必要なすべてのレビュー担当者が PR を承認し、必要なすべてのブランチ ポリシーが満たされたときに PR をオートコンプリートします。
- 下書きとしてマークする: PR を下書きの状態に設定して、レビューの準備ができていないことを示します。 下書き PR の場合は、[ 発行 ] を選択して下書きの状態を削除し、レビューの準備ができている状態に設定します。
- 閉じる: PR を閉じます。 破棄された PR の場合は、[ 再アクティブ化 ] を選択して復元します。
詳細については、「 pull request の完了」を参照してください。