pull requests について
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
pull request (PR) は、Azure Repos 上の Git リポジトリのコードを変更、レビュー、マージする方法です。 PR は、同じリポジトリ内のブランチから、またはリポジトリのフォーク内のブランチから送られます。 チームは、コードをメイン ブランチにマージする前に、PR を使用してコードをレビューし、変更に関するフィードバックを送ります。 レビュー担当者は、提案された変更をステップ実行し、コメントを残し、コードを承認または拒否するための投票を行うことができます。
この記事では、pull request のガイドラインと管理に関する考慮事項について説明します。 pull request を作成、表示、レビュー、実行する方法については、次の記事を参照してください。
Note
パフォーマンスと安定性の理由から、pull request に追加できるレビュー担当者の数は 1000 以下である必要があります。 1000 人を超えるレビュー担当者を追加しても、新しい pull request は作成されず、既存の pull request では 1000 人を超えるレビュー担当者を追加することはできません。
アクセス許可と前提条件
プロジェクトで Repos を有効にする必要があります。 Repos ハブと関連ページが表示されない場合は、Azure DevOps サービスのオンとオフの切り替えに関するページを参照して Repos を再度有効にしてください。
PR を表示またはレビューするには、Basic 以上のアクセス権を持つ Azure DevOps プロジェクトのメンバーである必要があります。
PR に参加するには、閲覧者セキュリティ グループのメンバーであるか、対応するアクセス許可を持っている必要があります。
PR を作成および実行するには、共同作成者セキュリティ グループのメンバーであるか、対応するアクセス許可を持っている必要があります。
注意
パブリック プロジェクトの場合、利害関係者アクセス権を付与されたユーザーは、Azure Repos へのフル アクセス権があります。
- プロジェクトで Repos を有効にする必要があります。 Repos ハブと関連ページが表示されない場合は、Azure DevOps サービスのオンとオフの切り替えに関するページを参照して Repos を再度有効にしてください。
- PR を表示またはレビューするには、Basic 以上のアクセス権を持つ Azure DevOps プロジェクトのメンバーである必要があります。 プロジェクト メンバーでない場合は、追加してもらいます。
- PR に参加するには、閲覧者セキュリティ グループのメンバーであるか、対応するアクセス許可を持っている必要があります。
- PR を作成および実行するには、共同作成者セキュリティ グループのメンバーであるか、対応するアクセス許可を持っている必要があります。
アクセス許可とアクセスの詳細については、「 既定の Git リポジトリとブランチのアクセス許可 および アクセス レベルについてを参照してください。
pull request の品質に関するフィードバック
高品質のレビューは、高品質のフィードバックから始まります。 PR に関する優れたフィードバックを行うためのヒントを次に示します。
- PR の所有者は、適切な担当者に PR をレビューしてもらう必要があり、レビュー担当者がコードの内容を把握していることを確認する必要があります。
- レビュー担当者は、実用的で建設的なフィードバックを送る必要があります。
- 所有者とレビュー担当者は、すばやくコメントして返信する必要があります。
PR の所有者は以下を行う必要があります。
- 必ず、適切なレビュー担当者を選択して PR に割り当てます。
- コードの働きを理解しているレビュー担当者を含めます。
- 他の分野で作業している開発者にアイデアを共有するよう依頼します。
- 変更の明確な説明を示します。
- pull request のテンプレートを使用してレビュー担当者のガイダンスを提供します。
- コードのビルドを、その中で実行されている修正プログラムまたは機能と共に提供します。
- コメントに返信し、提案を受け入れるか、提案された変更が望ましくない理由を説明します。
- PR の範囲外で適切な提案を行うには、新しい作業項目、ブランチ、PR を作成してそれらの変更を行います。
レビュー担当者は、次のタスクを実行する必要があります。
- 同意できない変更に関するフィードバックを送ります。
- 問題を特定し、別の方法では何をすべきかについて具体的な提案を行います。
- フィードバックが明確な意図を含み、理解しやすいことを確認します。
- コメントを残すか、変更に投票する
詳細については、「Git pull requests を使用したフィードバックの取得」を参照してください。
ブランチ ポリシーと pull request
チームは、常に適切な状態を保つために、リポジトリ内の重要なブランチ (main ブランチなど) に依存している可能性があります。 ブランチ ポリシーを設定すると、これらの保護されたブランチに対する変更についての PR を要求し、ブランチに直接プッシュされた変更を拒否できます。
PR にさらにポリシーを追加すると、重要なブランチのコード品質を向上できます。 提案されたコードのクリーン ビルドや複数のレビュー担当者からの承認などの追加要件を設定すると、重要なブランチの保護に役立ちます。
ブランチ ポリシーでは、PR に必要な承認の数を設定できます。 また、特定のレビュー担当者を、すべての PR または特定の PR で必須または任意とすることも設定できます。 PR は、必要な数の承認に達したら、他のレビュー担当者が変更を拒否した場合でもオートコンプリートするように設定できます。 ただし、PR をマージするには、まず必須のレビュー担当者が PR を承認する必要があります。 重要な PR の変更は、少なくとも 2 人のレビュー担当者がレビューおよび承認することがベスト プラクティスとなっています。
PR 作成者が新しい変更をプッシュするたびに投票をリセットするには、[レビュー担当者の最少数が必要です] ブランチ ポリシーで [新しい変更がある場合、コード レビュー担当者の投票をリセットする] を選択します。
次の表は、ブランチをカスタマイズするために定義できるポリシーをまとめたものです。 すべてのリポジトリおよびブランチのポリシーと設定の概要については、Git リポジトリの設定とポリシーに関するページを参照してください。
ポリシー
[Default]
説明
オフ
pull request 時に、指定した人数のレビュー担当者からの承認を必須とします。
オフ
pull request 時に、リンクされた作業項目を確認して、追跡可能性を強化します
オフ
pull request 時に、すべてのコメントが解決したことを確認します。
オフ
pull request が完了した際に使用できるマージの種類を制限して、ブランチ履歴を制御します。
オフ
1 つ以上のポリシーを追加して、pull request の変更を事前にマージしてビルドすることでコードを検証します。 ポリシーを有効または無効にすることもできます。
オフ
1 つ以上のポリシーを追加して、pull request を完了するために、他のサービスが成功状態を投稿することを必須とします。 ポリシーを有効または無効にすることもできます。
オフ
1 つ以上のポリシーを追加して、pull request がコードの特定の領域を変更するときに、コード レビュー担当者が自動的に追加されるように指定します。 ポリシーを有効または無効にすることもできます。
詳細については、次のトピックを参照してください。
状態の確認を定義してコードの品質を向上する
pull request とブランチ ポリシーを使用すると、チームはコードのレビューと自動ビルドの実行に関するベスト プラクティスを適用できます。 多くのチームには、追加の要件およびコードに対して行う追加の検証があります。 これらのニーズを満たすために、PR の状態の確認を PR ワークフローに統合できます。 PR の状態の確認を使用すると、成功または失敗の情報を PR に関連付けて、外部サービスでコード変更をプログラムを使用してサイン オフできます。
詳細については、次の記事を参照してください。
複数のマージ ベースの問題
場合によっては、PR に複数の真のマージ ベースがあり、このような状況によってセキュリティの問題が発生する可能性があります。 PR 内のファイルのバージョンがマージ ベース間で異なる場合、複数のマージ ベースの警告が発生します。 詳細と修復については、「複数のマージ ベース」をご覧ください。