ブランチ ポリシーと設定

  • [アーティクル]

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

ブランチ ポリシーは、チームが開発の重要なブランチを保護するのに役立ちます。 ポリシーによって、チームのコード品質と変更管理の基準が適用されます。 この記事では、ブランチ ポリシーを設定して管理する方法について説明します。 すべてのリポジトリおよびブランチのポリシーと設定の概要については、Git リポジトリの設定とポリシーに関するページを参照してください。

必要なポリシーが構成されているブランチは削除できず、すべての変更に pull request (PR) が必要になります。

前提条件

  • ブランチ ポリシーを設定するには、プロジェクト管理者セキュリティ グループのメンバーであるか、リポジトリ レベルの [ポリシーの編集] アクセス許可を持っている必要があります。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。

  • Azure DevOps CLI az repos policy コマンドを使用してブランチ ポリシーを管理する場合は、「Azure DevOps CLI の概要」の手順を実行します。

  • ブランチ ポリシーを設定するには、プロジェクト管理者セキュリティ グループのメンバーであるか、リポジトリ レベルの [ポリシーの編集] アクセス許可を持っている必要があります。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。

ブランチ ポリシーを構成する

ブランチ ポリシーを管理するには、[Repos]>[ブランチ] を選択して、Web ポータルで [ブランチ] ページを開きます。

[ブランチ] メニュー項目を示すスクリーンショット。

また、[プロジェクト設定]>[リポジトリ]>[ポリシー]>[ブランチ ポリシー]><[ブランチ名]> で、ブランチ ポリシーの設定を表示することもできます。

ポリシーがあるブランチには、ポリシー アイコンが表示されます。 そのアイコンを選択すると、ブランチのポリシー設定に直接移動できます。

ブランチ ポリシーを設定するには、管理する必要があるブランチを見つけます。 一覧を参照するか、右上の [ブランチ名の検索] ボックスでブランチを検索することができます。

ブランチの横にある [その他のオプション] アイコンを選択して、コンテキスト メニューから [ブランチ ポリシー] を選択します。

コンテキスト メニューからブランチ ポリシーを開く様子を示すスクリーンショット。

ページ内でブランチを見つけます。 リストを参照することも、右上の [すべてのブランチを検索] ボックスを使用してブランチを検索することもできます。

[ブランチ] ページを示すスクリーンショット。

... ボタンを選択します。 コンテキスト メニューから [Branch policies] を選択します。

コンテキスト メニューからブランチ ポリシーを開く様子を示すスクリーンショット。

ブランチの設定ページでポリシーを構成します。 ポリシーの種類ごとの説明と手順については、次のセクションを参照してください。

[Policies] ページでポリシーを構成します。 ポリシーの種類ごとの説明については、次のセクションを参照してください。 [変更の保存] を選択して、新しいポリシー構成を適用します。

[ポリシー] タブを示すスクリーンショット。

レビュー担当者の最少数を要求する

ソフトウェア開発プロジェクトには、コード レビューが重要です。 チームが PR を確実にレビューして承認するために、最少数のレビュー担当者からの承認を要求できます。 基本ポリシーでは、指定された数のレビュー担当者が拒否なくコードを承認する必要があります。

ポリシーを設定するには、[ブランチ ポリシー] で、[レビュー担当者の最少数が必要です] を [オン] に設定します。 必要なレビュー担当者数を入力し、次のいずれかのオプションを選択します。

コード レビューを要求するポリシーを有効にすることを示すスクリーンショット。

  • PR の作成者がその承認に投票できるようにするには、[要求者が自分の変更を承認することを許可する] を選択します。 選択しない場合、作成者は PR の [承認] に投票することはできますが、その投票はレビュー担当者の最少数にはカウントされません。

  • 職務の分離を適用するには、[最新のプッシュ元が自分の変更を承認することを禁止する] を選択します。 既定では、ソース ブランチに対するプッシュ アクセス許可を持つすべてのユーザーは、コミットを追加し、PR 承認に投票できます。 このオプションを選択すると、通常は自身の変更を承認できる場合でも、最新のプッシュ元の投票はカウントされません。

  • 一部のレビュー担当者が承認に反対の投票をする場合であっても PR 完了を可能にするには、[一部のレビュー担当者が待機中または拒否と投票した場合でも完了を許可する] を選択します。 最少数のレビュー担当者が、引き続き承認する必要があります。

  • [新しい変更がプッシュされたとき] で、以下を選択します。
    • 最後のソース ブランチの変更に少なくとも 1 つの承認投票を要求するには、[最後のイテレーションで少なくとも 1 つの承認が必要です] を選択します。
    • ソース ブランチが変更されるたびに、すべての承認投票を削除するが、拒否または待機の投票は保持するには、[すべての承認投票をリセット (投票は拒否または待機にはリセットされません)] を選択します。
    • 承認、拒否、待機の投票を含めて、ソース ブランチが変更されるたびにすべてのレビュー担当者の投票を削除するには、[すべてのコード レビュー担当者の投票をリセットします] を選択します。
  • [新しい変更がプッシュされたとき] で、以下を選択します。
    • 最後のソース ブランチの変更に少なくとも 1 つの承認投票を要求するには、[各イテレーションで少なくとも 1 つの承認を必要とする] を選択します。 ユーザーの承認は、そのユーザーによってプッシュされた過去の未承認のイテレーションに対してカウントされません。 そのため、最後のイテレーションに対する追加の承認は、別のユーザーが行う必要があります。 Azure DevOps Server 2022.1 以降で、[各イテレーションで少なくとも 1 つの承認を必要とする] をご利用になれます。
    • 最後のソース ブランチの変更に少なくとも 1 つの承認投票を要求するには、[最後のイテレーションで少なくとも 1 つの承認が必要です] を選択します。
    • ソース ブランチが変更されるたびに、すべての承認投票を削除するが、拒否または待機の投票は保持するには、[すべての承認投票をリセット (投票は拒否または待機にはリセットされません)] を選択します。
    • 承認、拒否、待機の投票を含めて、ソース ブランチが変更されるたびにすべてのレビュー担当者の投票を削除するには、[すべてのコード レビュー担当者の投票をリセットします] を選択します。

コード レビューを要求するボックスをオンにする

  • [要求者は自分で行った変更を承認することができます] が選択されていない場合、pull request の作成者は引き続き pull request で [承認] に投票できますが、その投票はレビュー担当者の最少数にはカウントされません。
  • いずれかのレビュー担当者が変更を拒否した場合、[一部のレビュー担当者が待機中または拒否と投票した場合でも完了を許可する] を選択しない限り、pull request は完了できません。
  • 新しい変更がソース ブランチにプッシュされたときに、コード レビュー担当者の投票をリセットできます。 [新しい変更がある場合、コード レビュー担当者の投票をリセットする] を選択します。

他のすべてのポリシーが合格した場合、作成者は、必要な数のレビュー担当者が承認したときに PR を完了できます。

リンクされた作業項目を確認する

作業項目管理の追跡では、PR と作業項目との関連付けを要求できます。 作業項目をリンクすると、変更の追加のコンテキストが提供され、更新によって作業項目の追跡プロセスが確実に実行されます。

ポリシーを設定するには、[ブランチ ポリシー] で [リンクされた作業項目を確認します] を [オン] に設定します。 この設定では、PR がマージされるように作業項目を PR にリンクする必要があります。 リンクされた作業項目がない場合に警告を表示するものの、pull request の完了を許可するには、設定を [省略可能] にします。

pull request でリンクされた作業項目を必須にするスクリーンショット。

pull request でリンクされた作業項目を必須にする

コメント解決の有無を確認する

[コメント解決の有無を確認する] ポリシーでは、すべての PR コメントが解決されているかどうかを確認します。

[コメント解決の有無を確認する] を [オン] に設定して、ブランチのコメント解決ポリシーを構成します。 次に、ポリシーを [必須] にするか、[省略可能] にするかを選択します。

コメント解決の確認のスクリーンショット。

pull request コメントの使用の詳細については、「pull request のレビュー」を参照してください。

[コメント解決の有無を確認する] を選択して、ブランチのコメント解決ポリシーを構成します。

コメント解決の有無を確認する

pull request コメントの使用の詳細については、「pull request のレビュー」を参照してください。

マージの種類を制限する

Azure Repos には複数のマージ戦略があり、既定では、それらのすべてが許可されます。 PR 完了のマージ戦略を適用することで、一貫したブランチ履歴を保持できます。

リポジトリで許可するマージの種類を制限するには、[マージの種類を制限する] を [オン] に設定します。

マージの種類の制限のスクリーンショット。

  • 基本マージ (早送りなし) では、親がターゲット ブランチとソース ブランチであるターゲットにマージ コミットが作成されます。
  • スカッシュ マージでは、ソース ブランチからの変更を使用して、ターゲット ブランチに 1 つのコミットを含む線形履歴が作成されます。 スカッシュ マージとスカッシュ マージがブランチ履歴に与える影響の詳細について確認してください。
  • リベースと早送りでは、マージ コミットなしで、ターゲット ブランチに対してソース コミットを再生することで、線形履歴を作成します。
  • マージ コミットによるリベースでは、ターゲットに対してソース コミットを再生し、マージ コミットも作成します。

注意

この機能は、Azure DevOps Server 2020 以降のバージョンに使用できます。

マージ戦略を適用する

pull request が完了するときにマージ戦略を適用することで、一貫したブランチ履歴を保持します。 [マージ戦略を適用する] を選択し、その戦略を使用して pull request のマージを要求するオプションを選択します。

マージ要件の設定

  • 早送りなしのマージ - このオプションは、pull request が閉じられ、ターゲット ブランチでマージ コミットが作成されるときに、ソース ブランチのコミット履歴をマージします。
  • スカッシュ マージ - スカッシュ マージを使用してすべての pull request を完了して、ソース ブランチからの変更を使用してターゲット ブランチに 1 つのコミットを作成します。 スカッシュ マージとスカッシュ マージがブランチ履歴に与える影響の詳細について確認してください。

ビルドの検証

PR が完了する前に PR の変更が正常にビルドされることを要求するポリシーを設定できます。 ビルド ポリシーは、中断を減らし、テスト結果が合格し続けるようにします。 開発ブランチで継続的インテグレーション (CI) を使用して問題を早期に検出する場合であっても、ビルド ポリシーは役立ちます。

ビルド検証ポリシーは、新しい PR が作成されるか、ブランチを対象とする既存の PR に変更がプッシュされたときに、新しいビルドをキューに入れます。 ビルド ポリシーはビルド結果を評価して、PR を完了できるかどうかを判別します。

重要

ビルド検証ポリシーを指定する前に、ビルド パイプラインが必要です。 パイプラインがない場合は、ビルド パイプラインの作成に関するページを参照してください。 お使いのプロジェクトの種類に一致するビルドの種類を選択します。

ビルド検証ポリシーを追加するには

  1. [ビルドの検証] の横にある + ボタンを選択します。

    [ビルドの検証] の横にある [追加] ボタンを示すスクリーンショット。

  2. [Set build policy] (ビルド ポリシーの設定) フォームに入力します。

    ビルド ポリシー設定のスクリーンショット。

    • [ビルド パイプライン] を選択します。

    • 必要に応じて、[パス フィルター] を設定します。 ブランチ ポリシーにおけるパス フィルターの詳細を参照してください。

    • [トリガー] の下で、[自動 (ソース ブランチの更新時)] または [手動] を選択します。

    • [ポリシー要件] の下で、[必須] または [省略可能] を選択します。 [必須] を選択した場合、PR を完了するにはビルドが正常に完了する必要があります。 [省略可能] を選択すると、ビルド エラーの通知が表示されますが、PR の完了は引き続き可能です。

    • ビルドの有効期限を設定して、保護されたブランチの更新が、開いている PR の変更を中断しないようにします。

      • <branch name> が更新されたらすぐ: このオプションは、ブランチが更新されるたびに PR ビルド ポリシーの状態を "失敗" に設定し、ビルドを再度キューに入れます。 この設定により、保護されたブランチが変更された場合でも PR の変更が正常にビルドされます。

        このオプションは、重要なブランチに変更がほとんどないチームに最適です。 ビジー状態の開発ブランチで作業しているチームにとっては、ブランチが更新されるたびにビルドを待機すると混乱を招く場合があります。

      • <branch name> が更新されてから <n> 時間後: このオプションは、合格したビルドが入力したしきい値より古い場合、保護されたブランチが更新されたときに現在のポリシーの状態の有効期限が切れます。 このオプションは、保護されたブランチが更新されたときにビルドを常に要求するか、要求しないかの間の妥協を表しています。 この選択により、保護されたブランチが頻繁に更新される場合のビルド数が減ります。

      • なし: 保護されたブランチを更新しても、ポリシーの状態は変わりません。 この値によりビルド数が減りますが、最近更新されていない PR の完了時に問題が生じる可能性があります。

    • このビルド ポリシーの表示名 (省略可能) を入力します。 この名前は、[ブランチ ポリシー] ページでポリシーを識別します。 表示名を指定しない場合、ポリシーではビルド パイプライン名が使用されます。

  3. [保存] を選択します。

PR の所有者が正常にビルドされた変更をプッシュすると、ポリシーの状態が更新されます。

<[branch name> が更新されたらすぐ] または [<branch name> が更新されてから <n> 時間後] ビルド ポリシーがある場合、以前のビルドが有効でなくなった場合、保護されたブランチが更新されるとポリシーの状態が更新されます。

注意

この機能は、Azure DevOps Server 2020 以降のバージョンに使用できます。

pull request を完了する前に、保護されたブランチを使用して pull request の変更が正常にビルドされることを要求するポリシーを設定します。 ビルド ポリシーは、中断を減らし、テスト結果が合格し続けるようにします。 開発ブランチで継続的インテグレーション (CI) を使用して問題を早期に検出する場合であっても、ビルド ポリシーは役立ちます。

ビルド検証ポリシーが有効になっている場合、新しい pull request が作成されたとき、またはブランチを対象とする既存の pull request に変更がプッシュされる場合、新しいビルドがキューに入れられます。 ビルド ポリシーはビルドの結果を評価して、pull request を完了できるかどうかを判別します。

重要

ビルド検証ポリシーを指定する前に、ビルド定義が必要です。 ない場合は、ビルド定義の作成に関するページを参照し、お使いのプロジェクトの種類に一致するビルドの種類を選択してください。

ビルド ポリシーの追加

[ビルド ポリシーの追加] を選択し、[ビルド ポリシーの追加] でオプションを構成します。

ビルド ポリシーの設定

  1. [ビルド定義] を選択します。

  2. [トリガー] の種類を選択します。 [自動 (ソース ブランチの更新時)] または [手動] を選択します。

  3. [ポリシー要件] を選択します。 [必須] を選択した場合、pull request を完了するにはビルドが正常に完了する必要があります。 [省略可能] を選択すると、ビルド エラーの通知が表示されますが、pull request の完了は引き続き可能です。

  4. ビルドの有効期限を設定して、保護されたブランチの更新が開いている pull request の変更を中断しないようにします。

    • branch name が更新されたらすぐ: このオプションは、保護されたブランチが更新されたときに pull request のビルド ポリシー状態を "失敗" に設定します。 ビルドを再度キューに入れてビルドの状態を更新します。 この設定により、保護されたブランチが変更された場合でも pull request の変更が正常にビルドされます。 このオプションは、変更の量が少ない重要なブランチがあるチームに最適です。 ビジー状態の開発ブランチで作業しているチームにとっては、保護されたブランチが更新されるたびにビルドの完了を待機すると混乱を招く場合があります。
    • branch name が更新されてから n 時間後: このオプションは、合格したビルドが入力されたしきい値より古い場合、保護されたブランチが更新されたときに現在のポリシーの状態の有効期限が切れます。 このオプションは、保護されたブランチが更新されたときにビルドを常に要求するか、要求しないかの間の妥協を表しています。 この選択肢は、保護されたブランチが頻繁に更新される場合にビルド数を削減するのに優れています。
    • なし: 保護されたブランチを更新しても、ポリシーの状態は変わりません。 この値により、ブランチのビルド数が減ります。 最近更新されていない pull request を閉じるときに問題が生じる可能性があります。

  5. このビルド ポリシーの表示名 (省略可能) を入力します。 この名前は、[ブランチ ポリシー] ページでポリシーを識別します。 表示名を指定しない場合、ポリシーではビルド定義名が使用されます。

  6. [保存] を選択します。

所有者が正常にビルドされた変更をプッシュすると、ポリシーの状態が更新されます。 [branch name が更新されたらすぐ] または [branch name が更新されてから n 時間後] ビルド ポリシーが選択されている場合、最新のビルドが有効でなくなった場合、保護されたブランチが更新されるとポリシーの状態が更新されます。

状態の確認

外部サービスでは、PR Status API を使用して、詳細な状態を PR に投稿できます。 追加サービスのブランチ ポリシーにより、外部のサービスが PR ワークフローに参加し、ポリシー要件を確立できるようになります。

[外部サービスに承認を求める] のスクリーンショット。

このポリシーの構成手順については、「外部サービスのブランチ ポリシーを構成する」を参照してください。

外部サービスに承認を求める

外部サービスでは、PR Status API を使用して、詳細な状態を PR に投稿できます。 追加サービスのブランチ ポリシーでは、外部のサービスが PR ワークフローに参加し、ポリシー要件を確立できます。

外部サービスに承認を求める

このポリシーの構成手順については、「外部サービスのブランチ ポリシーを構成する」を参照してください。

コードのレビュー担当者を自動的に含める

特定のディレクトリとファイル内のファイルを変更する pull request、またはリポジトリ内のすべての pull request に、レビュー担当者を自動的に追加できます。

  1. [自動的に追加されるレビュー担当者] の横にある + ボタンを選択します。

    必要なレビュー担当者の追加を示すスクリーンショット。

  2. [新しいレビュー担当者ポリシーの追加] 画面に入力します。

    [新しいレビュー担当者ポリシーの追加] 画面を示すスクリーンショット。

    • [レビュー担当者] にユーザーとグループを追加します。

    • レビュー担当者を自動的に追加するものの、pull request を完了するために承認を必要としない場合は、[省略可能] を選択します。

      または、次の時点まで pull request を完了できない場合は、[必須] を選択します。

      • レビュー担当者として追加されたすべての個人が変更を承認する。
      • レビュー担当者として追加されたすべてのグループの少なくとも 1 人のユーザーが変更を承認する。
      • 必要なグループが 1 つだけの場合は、指定した最少数のメンバーが変更を承認する。

    • 自動的に追加されるレビュー担当者を必要とするファイルとフォルダーを指定します。 ブランチ内のすべての pull request にレビュー担当者を要求するには、このフィールドを空白のままにします。

    • pull request の所有者が、このポリシーを満たすために自分の pull request を承認する投票ができる場合は、[要求者が自分の変更を承認することを許可する] を選択します。

    • pull request に表示される [アクティビティ フィード メッセージ] を指定できます。

  3. [保存] を選択します。

注意

この機能は、Azure DevOps Server 2020 以降のバージョンに使用できます。

リポジトリ内の特定のディレクトリとファイルのレビュー担当者を選択します。

パスと必要なレビュー担当者を入力する

これらのレビュー担当者は、それらのパスに沿ってファイルを変更する pull request に自動的に追加されます。 また、[アクティビティ フィード メッセージ] を指定することもできます。

レビュー担当者の自動追加

[必須] を選択した場合、pull request は次の時点まで完了できません。

  • パスのレビュー担当者として追加されたすべてのユーザーが変更を承認する。
  • パスに追加されたすべてのグループの少なくとも 1 人のユーザーが変更を承認する。
  • パスに追加されたすべてのグループに対して指定された数のレビュー担当者が、変更を承認する。

必要なレビュー担当者が自動的に追加されます

レビュー担当者を自動的に追加するものの、pull request を完了するために承認を必要としない場合は、[省略可能] を選択します。

[要求者は自分で行った変更を承認することができます] を選択できます。

必要なすべてのレビュー担当者がコードを承認したら、pull request を完了できます。

レビュー担当者が承認したことを示す pull request の状態

ブランチ ポリシーをバイパスする

場合によっては、ポリシー要件をバイパスすることが必要になる場合があります。 バイパス アクセス許可があると、変更をブランチに直接プッシュしたり、ブランチ ポリシーを満たさない pull request を完了したりできます。 ユーザーまたはグループにバイパス アクセス許可を付与できます。 バイパス アクセス許可のスコープをプロジェクト全体、リポジトリ、または単一のブランチに設定できます。

次の 2 つのアクセス許可を使用すると、ユーザーはブランチ ポリシーを異なる方法でバイパスできます。

  • [Pull requests を完了するときに、ポリシーをバイパスする] は、pull request の完了のみに適用されます。 このアクセス許可を持つユーザーは、pull request がポリシーを満たしていない場合でも、pull request を完了できます。

  • [プッシュするときにポリシーをバイパスする] は、ローカル リポジトリからのプッシュと Web 上で行われた編集に適用されます。 このアクセス許可を持つユーザーは、ポリシー要件を満たさずに、保護されたブランチに変更を直接プッシュできます。

ポリシー バイパス適用アクセス許可を示すスクリーンショット。

これらのアクセス許可の管理の詳細については、Git アクセス許可に関するページを参照してください。

TFS 2015 から TFS 2018 Update 2 では、[ポリシーの適用から除外] アクセス許可により、このアクセス許可を持つユーザーは次のアクションを実行できます。

  • 現在のブランチ ポリシー セットが満たされていない場合でも、ポリシーをオーバーライドしてプル リクエストを完了するようにオプトインします。
  • そのブランチにブランチ ポリシーが設定されている場合でも、ブランチに直接プッシュします。 このアクセス許可を持つユーザーがブランチ ポリシーをオーバーライドするプッシュを行うと、プッシュによってオプトイン ステップまたは警告なしでブランチ ポリシーが自動的にバイパスされることに注意してください。

重要

特にリポジトリ レベルとプロジェクト レベルでポリシーをバイパスする機能を付与する場合は注意してください。 ポリシーは、安全で準拠したソース コード管理の基礎となります。

パス フィルター

いくつかのブランチ ポリシーでは、パス フィルターが提供されます。 パス フィルターが設定されている場合、ポリシーはパス フィルターに一致するファイルのみに適用されます。 このフィールドを空白のままにすると、ブランチ内のすべてのファイルにポリシーが適用されます。

絶対パス (パスは / またはワイルドカードで始まる必要があります) とワイルドカードを指定できます。 例 :

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

; を区切り記号として使用して複数のパスを指定できます。 例:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

先頭に ! が付いているパスは、本来なら組み込まれているはずの場合でも除外されます。 例:

  • /WebApp/*;!/WebApp/Tests/* には、/WebApp/Tests のファイルを除く、/WebApp のすべてのファイルが含まれます
  • !/WebApp/Tests/* は、先頭に何も含まれていないため、指定されるファイルがありません

フィルターの順序が重要です。 フィルターは左から右に適用されます。

Q & A

ブランチ ポリシーがあるブランチに変更を直接プッシュできますか?

ブランチ ポリシーをバイパスするアクセス許可がない限り、必須ブランチ ポリシーがあるブランチに変更を直接プッシュすることはできません。 これらのブランチに対する変更は、pull request を介してのみ行うことができます。 必須ブランチ ポリシーがない場合は、"省略可能" ブランチ ポリシーがあるブランチに変更を直接プッシュできます。

オートコンプリートとは何ですか?

ブランチ ポリシーが構成されたブランチへの pull request には、[オートコンプリートの設定] ボタンがあります。 すべてのポリシーを満たしたら pull request を自動的に完了するには、このオプションを選択します。 オートコンプリートは、変更に関する問題が予想されない場合に便利です。

ブランチ ポリシーの条件はいつチェックされますか?

ブランチ ポリシーは、pull request の所有者が変更をプッシュするとき、およびレビュー担当者が投票するときに、サーバーで再評価されます。 ポリシーによってビルドがトリガーされた場合、ビルドの状態は、ビルドが完了するまで待機中に設定されます。

ブランチ ポリシーで XAML ビルド定義を使用できますか?

いいえ、ブランチ ポリシーで XAML ビルド定義を使用できません。

必要なコード レビュー担当者に使用できるワイルドカード文字は何ですか?

1 つのアスタリスク * は、スラッシュ / とバックスラッシュ \ の両方を含む任意の数の文字と一致します。 疑問符 ? は、任意の 1 文字と一致します。

例 :

  • *.sql は、.sql 拡張子を持つすべてのファイルと一致します。
  • /ConsoleApplication/* は、ConsoleApplication という名前のフォルダーにあるすべてのファイルと一致します。
  • /.gitattributes は、リポジトリのルートにある .gitattributes* ファイルと一致します。
  • */.gitignore は、リポジトリ内のすべての .gitignore ファイルと一致します。

必要なコード レビュー担当者のパスには大文字と小文字の区別がありますか?

いいえ。ブランチ ポリシーには、大文字と小文字の区別がありません。

複数のユーザーを必要なレビュー担当者として構成し、そのうちの 1 人のみが承認するように要求するにはどうすればよいですか?

ユーザーをグループに追加してから、そのグループをレビュー担当者として追加できます。 その後、グループの任意のメンバーが承認してポリシー要件を満たすことができます。

ポリシーをバイパスするアクセス許可があります。 pull request の状態でポリシー エラーが引き続き表示されるのはなぜですか?

構成されたポリシーは、pull request の変更がないか常に評価されます。 ポリシーをバイパスするアクセス許可を持つユーザーの場合、報告されるポリシーの状態はアドバイザリのみです。 バイパス アクセス許可を持つユーザーが承認する場合、エラー状態により pull request の完了がブロックされません。

[要求者が自分の変更を承認することを許可する] が設定されているときに、自分の pull request を完了できないのはなぜですか?

[レビュー担当者の最少数が必要です] ポリシーと [自動的に追加されるレビュー担当者] ポリシーの両方に、[要求者が自分の変更を承認することを許可する] オプションがあります。 各ポリシーで、設定はそのポリシーにのみ適用されます。 この設定は、他のポリシーには影響を与えません。

たとえば、pull request には次のポリシーが設定されます。

  • [レビュー担当者の最少数が必要です] には、少なくとも 1 人のレビュー担当者が必要です。
  • [自動的に追加されるレビュー担当者] には、自分または自分が参加しているチームがレビュー担当者として必要です。
  • [自動的に追加されるレビュー担当者] では、[要求者が自分の変更を承認することを許可する] が有効になっています。
  • [レビュー担当者の最少数が必要です] では、[要求者が自分の変更を承認することを許可する] が有効になっていません。

この場合、承認では [自動的に追加されるレビュー担当者] を満たしますが、[レビュー担当者の最少数が必要です] を満たさないため、pull request を完了できません。

また、[要求者が自分の変更を承認することを許可する] が設定されている場合でも自分の変更を承認できないようにする他のポリシー ([最新のプッシュ元が自分の変更を承認することを禁止する] など) もあります。

パス フィルター内のパスの先頭に / もワイルドカードもない場合、どうなりますか?

先頭に / もワイルドカードも付かないパス フィルターのパスは無効です。そのパスが指定されなかった場合と同じようにパス フィルターが評価されます。 このようなパスは、絶対ファイル パスの先頭にある / と一致しません。