ブランチポリシーを使用したコード品質の向上Improve code quality with branch policies

Azure Repos |Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018 |TFS 2017 |TFS 2015Azure Repos | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015

ブランチポリシーは、チームが開発の重要な ブランチ を保護するのに役立ちます。Branch policies help teams protect their important branches of development. ポリシーによって、チームのコード品質と変更管理の標準が適用されます。Policies enforce your team's code quality and change management standards.

ブランチポリシーの構成Configure branch policies

[リポジトリ] を選択して > 、web ポータルの [ブランチ] ページを開きます。Select Repos > Branches to open the Branches page in the web portal.

Web 上の [ブランチ] ページを開きます。

ページでブランチを見つけます。Locate your branch in the page. 一覧を参照するか、右上にある [ すべてのブランチを検索 ] ボックスを使用してブランチを検索することができます。You can browse the list or you can search for your branch using the Search all branches box in the upper right.

[ブランチ] ページ

[.. . ] ボタンを選択します。Select the ... button. コンテキストメニューから [ ブランチポリシー ] を選択します。Select Branch policies from the context menu.

コンテキストメニューから [ブランチポリシー] を開きます。

[ 設定 ] ページでポリシーを構成します。Configure policies on the Settings page. 各ポリシーの種類の説明については、次のセクションを参照してください。See the following sections for descriptions of each policy type.

[ ポリシー ] ページでポリシーを構成します。Configure your policies in the Policies page. 各ポリシーの種類の説明については、次のセクションを参照してください。See the following sections for descriptions of each policy type. [ 変更の保存 ] を選択して、新しいポリシー構成を適用します。Select Save changes to apply your new policy configuration.

[ポリシー] タブ

レビュー担当者の最小数が必要Require a minimum number of reviewers

ほとんどのソフトウェア開発プロジェクトでは、コードレビューがベストプラクティスです。Code reviews are a best practice for most software development projects. プル要求を完了する前にチームが変更をレビューするようにするには、[ 最小数のレビュー担当者が必要] を選択します。To require teams to review their changes before completing a pull request, select Require a minimum number of reviewers.

基本ポリシーでは、特定の数のレビュー担当者が、拒否されていないコードを承認する必要があります。The basic policy requires that a certain number of reviewers approve the code with no rejections.

[コードレビューを要求する] ポリシーを有効にする

  • [要求元が 自分の変更を承認できるようにする ] が選択されている場合、プル要求の作成者は承認に投票することがあります。If Allow requestors to approve their own changes is selected, the creator of the pull request may vote on its approval. そうでない場合でも、プル要求 に対して 投票を行うことができますが、投票は レビュー担当者の最小数 にはカウントされません。If not, they can still vote Approve on their pull request, but their vote won't count toward the Minimum number of reviewers.
  • 既定では、ソースブランチに対するプッシュアクセス許可を持つユーザーは、コミットを追加し、プル要求の承認に投票することができます。By default, anyone with push permissions on the source branch may both add commits and vote on the pull request's approval. [ 最新の pusher が自分の変更を承認 できないようにする] を有効にすることで、職務の分離を強制することができます。つまり、最新のプッシュを使用すると、pusher の投票が自動的にカウントされません。By enabling Prohibit the most recent pusher from approving their own changes, you can enforce segregation of duties - having the most recent push automatically makes the pusher's vote not count.
  • レビュー担当者が変更を拒否した場合、 一部のレビュー担当者が待機または却下に投票した場合でも、[完了を許可する] を選択しない限り、プル要求は完了できません。If any reviewer rejects the changes, the pull request can't finish unless you select Allow completion even if some reviewers vote to wait or reject.
  • ソースブランチに新しい変更がプッシュされると、コードレビュー担当者の投票をリセットできます。You can reset code reviewer votes when new changes are pushed to the source branch. [ 新しい変更がある場合は、コードレビュー担当者の投票をリセットする] を選択します。Select Reset code reviewer votes when there are new changes.

[コードレビューが必要] チェックボックスをオンにします。

  • 要求元が自分の変更を承認できる 場合でも、プル要求の作成者はプル要求 に対して 投票を行うことができますが、投票は レビュー担当者の最小数 にはカウントされません。If Requestors can approve their own changes isn't selected, the creator of the pull request can still vote Approve on their pull request, but their vote won't count toward the Minimum number of reviewers.
  • レビュー担当者が変更を拒否した場合、 一部のレビュー担当者が待機または却下に投票した場合でも、[完了を許可する] を選択しない限り、プル要求は完了できません。If any reviewer rejects the changes, the pull request can't finish unless you select Allow completion even if some reviewers vote to wait or reject.
  • ソースブランチに新しい変更がプッシュされると、コードレビュー担当者の投票をリセットできます。You can reset code reviewer votes when new changes are pushed to the source branch. [ 新しい変更がある場合は、コードレビュー担当者の投票をリセットする] を選択します。Select Reset code reviewer votes when there are new changes.

必要な数のレビュー担当者がプル要求を承認すると、完了することができます。When the required number of reviewers approve the pull request, it can finish.

注意

要求 元が独自の変更を承認できる のは、[ 最小数のレビュー担当者が必要 ] ポリシーにのみ適用されます。The Requestors can approve their own changes setting only applies to the Require a minimum number of reviewers policy. コードレビュー担当者が自動的にインクルードされるなど、他のポリシーには影響しません。It doesn't affect other policies such as Automatically include code reviewers. たとえば、Jamal Hartnett は、次のポリシーが構成されたプル要求を作成します。For example, Jamal Hartnett creates a pull request with the following policies configured:

  • レビュー担当者の最小数には 2 人のレビュー担当者が必要です。Minimum number of reviewers requires two reviewers.
  • 要求元が自分の変更を承認することはでき ません。Requestors can approve their own changes isn't set.
  • Fabrikam チーム グループは必須のレビュー担当者であり、Jamal はそのグループのメンバーです。The Fabrikam Team group is a required reviewer, and Jamal is a member of that group.

この例では、Jamal が Fabrikam チーム グループの一部であるため、自分の 承認 投票は必要なレビュー担当者ポリシーを満たしています。In this example, since Jamal is part of the Fabrikam Team group, his Approve vote satisfies the required reviewer policy. プル要求では、レビュー担当者の最小数 を満たすために2つの追加の 承認 投票が引き続き必要です。これは、投票がポリシーに対してカウントされないためです。The pull request still requires two additional Approve votes to satisfy the Minimum number of reviewers policy, since his vote doesn't count toward that policy.

リンクされた作業項目のチェックCheck for linked work items

分岐への変更に 作業項目管理の追跡が含まれるようにするには、プル要求と作業項目の間に関連付けが必要です。Require associations between pull requests and a work item to ensure that changes to your branch have work item management tracking. 作業項目をリンクすると、変更に関する追加のコンテキストが提供され、更新が作業項目追跡プロセスを通過するようになります。Linking work items provides additional context for your changes and ensures that updates go through your work item tracking process.

プル要求にリンクされた作業項目が必要

プル要求にリンクされた作業項目が必要

コメントの解決を確認するCheck for comment resolution

[ コメントの解決の確認] を選択して、分岐のコメント解決ポリシーを構成します。Configure a comment resolution policy for your branch by selecting Check for comment resolution.

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

プル要求のコメントの使用方法の詳細については、「 プル要求-コメントを残す」を参照してください。For more information on working with pull request comments, see Pull requests - leave comments.

[ コメントの解決の確認] を選択して、分岐のコメント解決ポリシーを構成します。Configure a comment resolution policy for your branch by selecting Check for comment resolution.

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

プル要求のコメントの使用方法の詳細については、「 プル要求-コメントを残す」を参照してください。For more information on working with pull request comments, see Pull requests - leave comments.

マージの種類を制限するLimit merge types

プル要求の完了時にマージ戦略を適用することで、一貫したブランチ履歴を維持します。Maintain a consistent branch history by enforcing a merge strategy when a pull request finishes. Azure Repos には複数のマージ方法があり、既定ではすべてが許可されます。Azure Repos has multiple merge strategies, and by default, all of them are allowed. [ マージの種類を制限 する] を選択して、リポジトリで許可するものを選択します。Select Limit merge types to pick which ones you'll allow in your repo.

マージの種類を制限する

  • Basic merge (高速転送不可) -ターゲットとソースブランチが親であるターゲットにマージコミットを作成します。Basic merge (no fast-forward) - creates a merge commit in the target whose parents are the target and source branches.
  • スカッシュ merge -ソースブランチからの変更を使用して、ターゲットブランチ内に1つのコミットで線形履歴を作成します。Squash merge - creates a linear history with a single commit in the target branch with the changes from the source branch. スカッシュマージの詳細 と、それがブランチ履歴に与える影響について説明します。Learn more about squash merging and how it affects your branch history.
  • リベースと高速転送 -マージコミットを使用せずにソースコミットをターゲットブランチに再生することによって、線形の履歴を作成します。Rebase and fast-forward - creates a linear history by replaying source commits onto the target branch with no merge commit.
  • マージコミットを使用したリベース -ソースコミットをターゲットに再生し、引き続きマージコミットを作成します。Rebase with merge commit - replays the source commits onto the target and still creates a merge commit.

マージ戦略を適用するEnforce a merge strategy

プル要求の完了時にマージ戦略を適用することで、一貫したブランチ履歴を維持します。Maintain a consistent branch history by enforcing a merge strategy when a pull request finishes. [ マージ戦略を適用 する] を選択し、その方法を使用してプル要求をマージすることを要求するオプションを選択します。Select Enforce a merge strategy and pick an option to require that pull requests merge using that strategy.

マージ要件の設定

  • [早送りマージなし]-プル要求が閉じられ、ターゲットブランチにマージコミットが作成されるときに、このオプションによってソースブランチのコミット履歴がマージされます。No fast-forward merge - This option merges the commit history of the source branch when the pull request closes and creates a merge commit in the target branch.
  • スカッシュ merge -スカッシュ merge を使用してすべてのプル要求を完了し、ソースブランチからの変更を含む単一のコミットをターゲットブランチに作成します。Squash merge - Complete all pull requests with a squash merge, creating a single commit in the target branch with the changes from the source branch. スカッシュマージの詳細 と、それがブランチ履歴に与える影響について説明します。Learn more about squash merging and how it affects your branch history.

ビルド検証Build validation

プル要求を完了する前に、保護されたブランチで正常にビルドするために、プル要求の変更を必要とするポリシーを設定します。Set a policy requiring changes in a pull request to build successfully with the protected branch before the pull request can be completed. ビルドポリシーは、中断を減らし、テスト結果を成功させます。Build policies reduce breaks and keep your test results passing. ビルドポリシーは、開発ブランチで 継続的インテグレーション (CI) を使用している場合でも、早期に問題を発見するのに役立ちます。Build policies help even if you're using continuous integration (CI) on your development branches to catch problems early.

ビルド検証ポリシーが有効になっている場合、新しいプル要求が作成されるか、またはブランチをターゲットとする既存のプル要求に変更がプッシュされると、新しいビルドがキューに登録されます。If a build validation policy is enabled, a new build is queued when either a new pull request is created, or if changes are pushed to an existing pull request targeting the branch. ビルドポリシーは、ビルドの結果を評価して、プル要求を完了できるかどうかを判断します。The build policy then evaluates the results of the build to determine whether the pull request can be completed.

重要

ビルド検証ポリシーを指定する前に、ビルドパイプラインが必要です。Before specifying a build validation policy, you must have a build pipeline. ない場合は、「 ビルドパイプラインを作成する 」および「プロジェクトの種類に一致するビルドの種類を選択する」を参照してください。If you don't have one, see Create a build pipeline and choose the type of build that matches your project type.

ビルドポリシーの追加

[ + ビルド検証] の横にあるボタンをクリックします。Choose the + button next to Build validation.

ビルドポリシー設定

  1. ビルドパイプライン を選択します。Select the Build pipeline.

  2. 必要に応じて、 パスフィルター を設定します。Optionally set a Path filter. パスフィルターの詳細については、「ブランチポリシー」を参照してください。Learn more about path filters in branch policies.

  3. トリガー の種類を選択します。Choose the type of Trigger. [ 自動] (ソースブランチが更新されたとき) または [ 手動] を選択します。Select Automatic (whenever the source branch is updated) or Manual.

  4. ポリシー要件 を選択します。Select the Policy requirement. [ 必須] を選択した場合は、プル要求を完了するためにビルドが正常に完了する必要があります。If you choose Required, builds must complete successfully to complete pull requests. ビルドエラーの通知を提供し、プル要求を完了することを許可する場合は、[ 省略可能 ] を選択します。Choose Optional to provide a notification of the build failure but still allow pull requests to complete.

  5. ビルドの有効期限を設定して、保護されたブランチの更新が開いているプル要求の変更を中断しないようにします。Set a build expiration to make sure that updates to your protected branch don't break changes for open pull requests.

    • [ branch name 更新時に直ち に]: このオプションは、保護されたブランチが更新されたときにプル要求のビルドポリシーの状態を [失敗] に設定します。Immediately when branch name is updated: This option sets the build policy status in a pull request to failed when the protected branch is updated. ビルドの状態を更新するためにビルドをキューへします。Requeue a build to refresh the build status. この設定により、保護されたブランチが変更された場合でも、プル要求の変更が正常にビルドされるようになります。This setting ensures that the changes in pull requests build successfully even as the protected branch changes. このオプションは、重要な分岐の変更量が少ないチームに最適です。This option is best for teams that have important branches with a lower volume of changes. ビジー状態の開発ブランチで作業しているチームは、保護されたブランチが更新されるたびにビルドが完了するのを待つことができます。Teams working in busy development branches may find it disruptive to wait for a build to complete every time the protected branch is updated.
    • [ n branch name が更新された場合]: このオプションを選択すると、成功したビルドが入力したしきい値よりも古い場合に、保護されたブランチが更新されると、現在のポリシーの状態が期限切れになりますAfter n hours if branch name has been updated: This option expires the current policy status when the protected branch updates if the passing build is older than the threshold entered. このオプションは、保護されたブランチの更新時に常にビルドを必要とする場合と、それを必要としない場合の妥協です。This option is a compromise between always requiring a build when the protected branch updates and never requiring one. この選択は、保護されたブランチが頻繁に更新される場合にビルド数を減らすために適しています。This choice is excellent for reducing the number of builds when your protected branch has frequent updates.
    • Never: 保護されたブランチの更新では、ポリシーの状態が変更されません。Never: Updates to the protected branch don't change the policy status. この値を指定すると、ブランチのビルド数が減少します。This value reduces the number of builds for your branch. 最近更新されていないプル要求を閉じると、問題が発生する可能性があります。It can cause problems when closing pull requests that haven't updated recently.
  6. このビルドポリシーのオプションの 表示名 を入力します。Enter an optional Display name for this build policy. この名前は、[ ブランチポリシー ] ページでポリシーを識別します。This name identifies the policy on the Branch policies page. 表示名を指定しない場合、ポリシーはビルドパイプライン名を使用します。If you don't specify a display name, the policy uses the build pipeline name.

  7. [保存] を選択します。Select Save.

正常にビルドされた変更を所有者がプッシュすると、ポリシーの状態が更新されます。When the owner pushes changes that build successfully, the policy status is updated. branch name が更新 されたとき、または [ n branch name 更新され たビルドポリシー] が選択された時間が経過した後にが表示される場合、最新のビルドが有効でなくなったときに保護されたブランチが更新されると、ポリシーの状態が更新されます。If you have an Immediately when branch name is updated or After n hours if branch name has been updated build policy chosen, the policy status updates when the protected branch is updated if the most recent build is no longer valid.

プル要求を完了する前に、保護されたブランチで正常にビルドするために、プル要求の変更を必要とするポリシーを設定します。Set a policy requiring changes in a pull request to build successfully with the protected branch before the pull request can be completed. ビルドポリシーは、中断を減らし、テスト結果を成功させます。Build policies reduce breaks and keep your test results passing. ビルドポリシーは、開発ブランチで 継続的インテグレーション (CI) を使用している場合でも、早期に問題を発見するのに役立ちます。Build policies help even if you're using continuous integration (CI) on your development branches to catch problems early.

ビルド検証ポリシーが有効になっている場合、新しいプル要求が作成されるか、またはブランチをターゲットとする既存のプル要求に変更がプッシュされると、新しいビルドがキューに登録されます。If a build validation policy is enabled, a new build is queued when either a new pull request is created, or if changes are pushed to an existing pull request targeting the branch. ビルドポリシーは、ビルドの結果を評価して、プル要求を完了できるかどうかを判断します。The build policy then evaluates the results of the build to determine whether the pull request can be completed.

重要

ビルド検証ポリシーを指定する前に、ビルド定義が必要です。Before specifying a build validation policy, you must have a build definition. ない場合は、「 ビルド定義を作成する 」および「プロジェクトの種類に一致するビルドの種類を選択する」を参照してください。If you don't have one, see Create a build definition and choose the type of build that matches your project type.

ビルドポリシーの追加

[ ビルドポリシーの追加 ] を選択し、[ ビルドポリシーの追加] でオプションを構成します。Choose Add build policy and configure your options in Add build policy.

ビルドポリシー設定

  1. ビルド定義 を選択します。Select the Build definition.

  2. トリガー の種類を選択します。Choose the type of Trigger. [ 自動] (ソースブランチが更新されたとき) または [ 手動] を選択します。Select Automatic (whenever the source branch is updated) or Manual.

  3. ポリシー要件 を選択します。Select the Policy requirement. [ 必須] を選択した場合は、プル要求を完了するためにビルドが正常に完了する必要があります。If you choose Required, builds must complete successfully to complete pull requests. ビルドエラーの通知を提供し、プル要求を完了することを許可する場合は、[ 省略可能 ] を選択します。Choose Optional to provide a notification of the build failure but still allow pull requests to complete.

  4. ビルドの有効期限を設定して、保護されたブランチの更新が開いているプル要求の変更を中断しないようにします。Set a build expiration to make sure that updates to your protected branch don't break changes for open pull requests.

    • [ branch name 更新時に直ち に]: このオプションは、保護されたブランチが更新されたときにプル要求のビルドポリシーの状態を [失敗] に設定します。Immediately when branch name is updated: This option sets the build policy status in a pull request to failed when the protected branch is updated. ビルドの状態を更新するためにビルドをキューへします。Requeue a build to refresh the build status. この設定により、保護されたブランチが変更された場合でも、プル要求の変更が正常にビルドされるようになります。This setting ensures that the changes in pull requests build successfully even as the protected branch changes. このオプションは、重要な分岐の変更量が少ないチームに最適です。This option is best for teams that have important branches with a lower volume of changes. ビジー状態の開発ブランチで作業しているチームは、保護されたブランチが更新されるたびにビルドが完了するのを待つことができます。Teams working in busy development branches may find it disruptive to wait for a build to complete every time the protected branch is updated.
    • [ n branch name が更新された場合]: このオプションを選択すると、成功したビルドが入力したしきい値よりも古い場合に、保護されたブランチが更新されると、現在のポリシーの状態が期限切れになりますAfter n hours if branch name has been updated: This option expires the current policy status when the protected branch updates if the passing build is older than the threshold entered. このオプションは、保護されたブランチの更新時に常にビルドを必要とする場合と、それを必要としない場合の妥協です。This option is a compromise between always requiring a build when the protected branch updates and never requiring one. この選択は、保護されたブランチが頻繁に更新される場合にビルド数を減らすために適しています。This choice is excellent for reducing the number of builds when your protected branch has frequent updates.
    • Never: 保護されたブランチの更新では、ポリシーの状態が変更されません。Never: Updates to the protected branch don't change the policy status. この値を指定すると、ブランチのビルド数が減少します。This value reduces the number of builds for your branch. 最近更新されていないプル要求を閉じると、問題が発生する可能性があります。It can cause problems when closing pull requests that haven't updated recently.
  5. このビルドポリシーのオプションの 表示名 を入力します。Enter an optional Display name for this build policy. この名前は、[ ブランチポリシー ] ページでポリシーを識別します。This name identifies the policy on the Branch policies page. 表示名を指定しない場合、ポリシーではビルド定義名が使用されます。If you don't specify a display name, the policy uses the build definition name.

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

正常にビルドされた変更を所有者がプッシュすると、ポリシーの状態が更新されます。When the owner pushes changes that build successfully, the policy status is updated. branch name が更新 されたとき、または [ n branch name 更新され たビルドポリシー] が選択された時間が経過した後にが表示される場合、最新のビルドが有効でなくなったときに保護されたブランチが更新されると、ポリシーの状態が更新されます。If you have an Immediately when branch name is updated or After n hours if branch name has been updated build policy chosen, the policy status updates when the protected branch is updated if the most recent build is no longer valid.

状態の確認Status checks

外部サービスは、PR STATUS API を使用して、pr に詳細な状態を通知できます。External services can use the PR Status API to post detailed status to your PRs. 追加のサービスの分岐ポリシーを使用すると、これらのサードパーティのサービスが PR ワークフローに参加し、ポリシー要件を確立できます。The branch policy for additional services brings the ability for those third-party services to participate in the PR workflow and establish policy requirements.

外部サービスの承認を要求する

このポリシーを構成する手順については、「 外部サービスのブランチポリシーの構成」を参照してください。For instructions on configuring this policy, see Configure a branch policy for an external service.

外部サービスからの承認が必要Require approval from external services

外部サービスは、PR STATUS API を使用して、pr に詳細な状態を通知できます。External services can use the PR Status API to post detailed status to your PRs. 追加のサービスの分岐ポリシーを使用すると、これらのサードパーティのサービスが PR ワークフローに参加し、ポリシー要件を確立できます。The branch policy for additional services brings the ability for those third-party services to participate in the PR workflow and establish policy requirements.

外部サービスの承認を要求する

このポリシーを構成する手順については、「 外部サービスのブランチポリシーの構成」を参照してください。For instructions on configuring this policy, see Configure a branch policy for an external service.

コードレビュー担当者を自動的に含めるAutomatically include code reviewers

リポジトリ内の特定のディレクトリおよびファイルのレビュー担当者を選択します。Select reviewers for specific directories and files in your repo.

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

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

これらのレビュー担当者は、これらのパスに沿ってファイルを変更するプル要求に自動的に追加されます。These reviewers are automatically added to pull requests that change files along those paths. アクティビティフィードメッセージ を指定することもできます。You can also specify an Activity feed message.

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

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

[ 必須] を選択した場合、プル要求は次のまで完了できません。If you select Required, then the pull request can't be completed until:

  • パスのレビュー担当者として追加されたすべてのユーザーが、変更を承認します。Every user added as a reviewer for the path approves the changes.
  • パスに追加されたすべてのグループの少なくとも1人が、変更を承認します。At least one person in every group added to the path approves the changes.
  • パスに追加されたすべてのグループに対して指定されたレビュー担当者の数によって、変更が承認されます。The number of reviewers specified for every group added to the path approves the changes.

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

レビュー担当者を自動的に追加するが、プル要求を完了するために承認を必要としない場合は、[ 省略可能 ] を選択します。Select Optional if you want to add reviewers automatically, but not require their approval to complete the pull request.

[ 要求元が自分の変更を承認できるように する] を選択できます。You can select Allow requestors to approve their own changes.

[要求元] を選択すると 、自分の変更を承認でき ます。You can select Requestors can approve their own changes.

すべての必要なレビュー担当者がコードを承認すると、プル要求を完了できます。When all required reviewers approve the code, you can complete the pull request.

レビュー担当者が承認したことを示すプル要求の状態

分岐ポリシーをバイパスするBypass branch policies

場合によっては、ポリシーの要件を省略する必要があります。In some cases, you need to bypass policy requirements. バイパスを使用すると、ブランチポリシーが満たされていない場合でも、変更を分岐に直接プッシュしたり、プル要求を完了したりすることができます。Bypassing lets you push changes to the branch directly or complete a pull request even if branch policies aren't satisfied. 前の一覧のアクセス許可をユーザーまたはグループに付与することができます。You can grant a permission from the previous list to a user or group. このアクセス許可のスコープは、プロジェクト全体、リポジトリ、または1つの分岐に限定できます。You can scope this permission to an entire project, a repo, or a single branch. このアクセス許可は、他の Git アクセス許可と共に管理します。Manage this permission along with other Git permissions.

ホストされたサービスを含め Azure DevOps Server 2019 以降では、ユーザーがブランチポリシーを異なる方法でバイパスできるようにするためのアクセス許可が2つあります。In Azure DevOps Server 2019 and above, including the hosted service, there are two permissions that allow users to bypass branch policy in different ways. プル要求の完了時にポリシーをバイパス するプル要求の完了にのみ適用されます。Bypass policies when completing pull requests applies only to pull requests completion. プッシュがローカルリポジトリからプッシュに適用さ れる場合はポリシーをバイパス し、web で行った編集を行います。Bypass policies when pushing applies to pushes from a local repository and edits made on the web.

これ により、前の1つのアクセス許可が置き換えられます。This replaces the previous single permission.

ポリシー適用アクセス許可からの除外

Tfs 2015 から TFS 2018 Update 2 までは、 ポリシー適用から除外 されるアクセス許可によって、このアクセス許可を持つユーザーは次の操作を実行できます。In TFS 2015 through TFS 2018 Update 2, the Exempt from policy enforcement permission allows users with this permission to perform the following actions:

  • プル要求の完了時に、ポリシーをオーバーライドし、現在のブランチポリシーのセットが満たされていない場合でもプル要求を完了することをオプトインします。When completing a pull request, opt-in to override policies and complete a pull request even if the current set of branch policies is not satisfied.
  • 分岐に分岐ポリシーが設定されている場合でも、ブランチに直接プッシュします。Push directly to a branch even if that branch has branch policies set. このアクセス許可を持つユーザーが、分岐ポリシーをオーバーライドするプッシュを行うと、プッシュでは、オプトインステップも警告もなく分岐ポリシーが自動的にバイパスされることに注意してください。Note that when a user with this permission makes a push that would override branch policy, the push automatically bypasses branch policy with no opt-in step or warning.

重要

特にリポジトリとプロジェクトレベルでポリシーをバイパスする機能を許可する場合は注意してください。Use caution when granting the ability to bypass policy, especially at the repo and project level. ポリシーは、安全で準拠しているソースコード管理の基礎となります。Policies are a cornerstone of secure and compliant source code management.

パスフィルターPath filters

いくつかの分岐ポリシーはパスフィルターを提供します。Several branch policies offer path filters. パスフィルターを設定すると、フィルターに一致するファイルが変更された場合にのみポリシーが適用されます。If a path filter is set, the policy will only apply when files which match the filter are changed. このフィールドを空白のままにすると、ポリシーは常に適用されます。Leaving this field blank means that the policy will always apply.

絶対パスとワイルドカードを指定できます。You can specify absolute paths and wildcards. 例 :Examples:

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

区切り記号としてを使用して、複数のパスを指定でき ; ます。You can specify multiple paths using ; as a separator. 例:Example:

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

で始まるパス ! は、含まれていない場合は除外されます。Paths prefixed with ! are excluded if they would otherwise be included. 例:Example:

  • /WebApp/*;!/WebApp/Tests/*-以外のすべてのファイルが含まれます。 /WebApp``/WebApp/Tests/WebApp/*;!/WebApp/Tests/* - includes all files in /WebApp except files in /WebApp/Tests
  • !/WebApp/Tests/* -最初は何も含まれていないため、ファイルは指定しません。!/WebApp/Tests/* - specifies no files, since nothing is included first

フィルターの順序は重要です。The order of filters is significant. これらは左から右に適用されます。They're applied left-to-right.

Q & AQ & A

ブランチポリシーの構成後に、変更を分岐に直接プッシュできますか。Can I push changes directly to a branch after a branch policy is configured?

いいえ。No. 必要なブランチポリシーを設定した後は、変更を分岐に直接プッシュすることはできません。After you set up a required branch policy, you can't directly push changes to the branch. 分岐への変更は、 プル要求によってのみ行われます。Changes to the branch are only made through pull requests.

注意

  • ブランチポリシーをバイパスできるアクセス許可がある場合は、必要なブランチポリシーが構成された後に分岐に直接プッシュできます。If you have permissions that allow you to bypass branch policies you can push directly to a branch after a required branch policy is configured.
  • 省略可能な分岐ポリシーを構成し、必須の分岐ポリシーを構成しなかった場合は、変更を分岐に直接プッシュできます。If you configured optional branch policies, but no required branch policies, you can push changes directly to a branch.

オートコンプリートとはWhat is auto-complete?

ブランチポリシーが構成されたブランチにプル要求を行うと、プル要求に対して [ オートコンプリートの設定 ] ボタンが有効になります。When you make a pull request into a branch with branch policies configured, it enables the Set auto-complete button for the pull request. このオプションを使用すると、変更に問題がない場合に 自動的に完了 します。Use this option to automatically complete if you don't expect any problems with your changes. プル要求は、すべてのポリシーを満たした後に完了しました。Your pull request finished once it meets all policies.

ブランチポリシーで設定されている条件はどのような場合にオンになりますか。When are the conditions set in branch policies checked?

ブランチポリシーは、変更がプッシュされ、レビュー担当者に投票されると、サーバー上で再評価されます。Branch policies are reevaluated on the server as changes are pushed and reviewers vote. ポリシーによってトリガーされたビルドがある場合、ビルドの状態は、ビルドが完了するまで待機するように設定されます。If there's a build triggered by the policy, the build status is set to waiting until the build completes.

ブランチポリシーで XAML ビルド定義を使用できますか。Can I use XAML build definitions in branch policies?

ブランチポリシーでは、XAML ビルド定義を使用できません。You can't use XAML build definitions in branch policies.

必要なコードレビュー担当者には、どのワイルドカード文字を使用できますか。What wildcard characters can you use for required code reviewers?

1つのアスタリスク ( * ) と、スラッシュ () / とバックスラッシュ () の両方を含む任意の数の文字に一致し \ ます。Single asterisks (*) and match any number of characters, including both forward-slashes (/) and back-slashes (\). 疑問符 ( ? ) は任意の1文字と一致します。Question marks (?) match any single character.

例 :Examples:

  • *.sqlすべてのファイルと .sql 拡張子を一致させ ます。*.sql match all files with the .sql extension
  • /ConsoleApplication/*Consoleapplication という名前のフォルダーにあるすべてのファイルを照合します。/ConsoleApplication/* match all files under the folder named ConsoleApplication
  • /.gitattributesリポジトリのルートにある .gitattributes ファイルと一致し ます。/.gitattributes match the .gitattributes file in the root of the repo
  • */.gitignore リポジトリ内の任意の gitignore と一致します*/.gitignore match any .gitignore file in the repo

必要なコードレビュー担当者のパスは大文字と小文字を区別しますか。Are the required code reviewer paths case-sensitive?

いいえ、現時点ではブランチポリシーの大文字と小文字は区別されません。No, branch policies aren't case-sensitive at this time.

必須のレビュー担当者として複数のユーザーを構成する方法はありますが、そのうちの1人だけが承認する必要がありますか。How can I configure multiple users as required reviewers, but only require that one of them approve?

ユーザーを グループに追加し、そのグループをレビュー担当者として追加することができます。You can add the users to a group, and then add the group as a reviewer. グループのすべてのメンバーは、そのグループがポリシー要件を満たすことを承認できます。Any member of the group can then approve for the group to meet the policy requirement.

"ポリシーから除外する" アクセス許可が設定されていますが、プル要求の状態でポリシーエラーが表示されるのはなぜですか。I have the exempt from policy permission set, why am I still seeing policy failures in the pull request status?

構成されたポリシーは、プル要求に変更を加えた場合でも評価されます。The configured policies are still evaluated when you add changes to a pull request. ポリシー適用から除外されているユーザーに対してもポリシーが適用されます。Policies apply even for users that are exempt from policy enforcement. 除外ユーザーの場合、ポリシーの状態は "アドバイザリのみ" であり、プル要求の完了をブロックしません。For exempt users, policy status is advisory only and doesn't block completion of the pull request.

高度なポリシーの構成に関する詳細情報はどこで入手できますか。Where can I get more information on advanced policy configurations?

詳細については、 REST API のドキュメント を参照してください。Check out the REST API documentation for more details.