Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019
As políticas de filiais ajudam as equipes a proteger seus ramos importantes de desenvolvimento. As políticas reforçam a qualidade do código e os padrões de gerenciamento de alterações da sua equipe. Este artigo descreve como definir e gerenciar políticas de filial. Para obter uma visão geral de todas as políticas e configurações de repositório e ramificação, consulte Configurações e políticas do repositório Git.
Uma ramificação com as políticas necessárias configuradas não pode ser excluída e requer solicitações pull (PRs) para todas as alterações.
Pré-requisitos
Para definir políticas de filial, você deve ser membro do grupo de segurança Administradores de Projeto ou ter permissões de Editar políticas no nível do repositório. Para obter mais informações, consulte Definir permissões do repositório Git.
Se você quiser usar os comandos de política az repos da CLI do Azure DevOps para gerenciar políticas de filial, siga as etapas em Introdução à CLI do Azure DevOps.
Para definir políticas de filial, você deve ser membro do grupo de segurança Administradores de Projeto ou ter permissões de Editar políticas no nível do repositório. Para obter mais informações, consulte Definir permissões do repositório Git.
Para gerenciar políticas de filial, selecione Repos>Branches para abrir a página Branches no portal da Web.
Você também pode acessar as configurações de política de ramificação com Configurações do>projeto, Políticas de repositório>,>Políticas de filial,<>Nome> da filial.
As ramificações que têm políticas exibem um ícone de política. Você pode selecionar o ícone para ir diretamente para as configurações de política da filial.
Para definir políticas de filial, localize a ramificação que você deseja gerenciar. Você pode navegar na lista ou pesquisar sua filial na caixa Pesquisar nome da filial no canto superior direito.
Selecione o ícone Mais opções ao lado da ramificação e, em seguida, selecione Políticas de ramificação no menu de contexto.
Localize sua filial na página. Você pode navegar na lista ou pesquisar sua filial usando a caixa Pesquisar todas as filiais no canto superior direito.
Selecione o botão ... . Selecione Políticas de ramificação no menu de contexto.
Configure políticas na página de configurações da filial. Consulte as seções a seguir para obter descrições e instruções para cada tipo de política.
Configure suas políticas na página Políticas . Consulte as seções a seguir para obter descrições de cada tipo de política. Selecione Salvar alterações para aplicar sua nova configuração de política.
Você pode usar a CLI do Azure DevOps para listar ou mostrar políticas para uma filial ou repositório.
az repos policy list [--branch]
[--detect {false, true}]
[--org]
[--project]
[--query-examples]
[--repository-id]
[--subscription]
Parâmetros
Parâmetro
Description
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org, organization
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
query-examples
String JMESPath recomendada. Você pode copiar uma das consultas e colá-la após o --query parâmetro entre aspas duplas para ver os resultados. Você pode adicionar uma ou mais palavras-chave posicionais para que as sugestões sejam baseadas nessas palavras-chave.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Exemplo
O comando a seguir retorna todas as políticas de ramificação em vigor na main ramificação do repositório da Fabrikam, ID d28cd374-e7f0-4b1f-ad60-f349f155d47c. Você pode obter o ID do repositório executando az repos list.
Este exemplo usa a seguinte configuração padrão: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
az repos policy list --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --branch main --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- --------------------------- ------------- ------------ ------------------------------------ ---------------
3 Work item linking False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
5 Minimum number of reviewers True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
6 Comment requirements False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
12 Required reviewers True False d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
13 Required reviewers False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
az repos policy show --id
[--detect {false, true}]
[--org]
[--project]
[--query-examples]
[--subscription]
Parâmetros
Parâmetro
Description
id, policy-id
ID da política. Necessário.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org, organization
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
query-examples
String JMESPath recomendada. Você pode copiar uma das consultas e colá-la após o --query parâmetro entre aspas duplas para ver os resultados. Você pode adicionar uma ou mais palavras-chave posicionais para que as sugestões sejam baseadas nessas palavras-chave.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Os comandos da CLI do Azure DevOps não são suportados para o Servidor de DevOps do Azure.
Exigir um número mínimo de revisores
As revisões de código são importantes para projetos de desenvolvimento de software. Para garantir que as equipes analisem e aprovem RPs, você pode exigir a aprovação de um número mínimo de revisores. A política básica requer que um número especificado de revisores aprove o código, sem rejeições.
Para definir a política, em Políticas de Filial, defina Exigir um número mínimo de revisores como Ativado. Insira o número necessário de revisores e selecione uma das seguintes opções:
Selecione Permitir que os solicitantes aprovem suas próprias alterações para permitir que o criador de um RP vote em sua aprovação. Caso contrário, o criador ainda pode votar Aprovar no PR, mas seu voto não conta para o número mínimo de revisores.
Selecione Proibir o empurrador mais recente de aprovar suas próprias alterações para impor a segregação de funções. Por padrão, qualquer pessoa com permissão push na ramificação de origem pode adicionar confirmações e votar na aprovação de RP. Selecionar esta opção significa que o voto do empurrador mais recente não conta, mesmo que ele possa normalmente aprovar suas próprias alterações.
Selecione Permitir conclusão mesmo que alguns revisores votem para aguardar ou rejeitar para permitir a conclusão de RP, mesmo que alguns revisores votem contra a aprovação. O número mínimo de revisores ainda deve ser aprovado.
Em Quando novas alterações são enviadas por push:
Selecione Exigir pelo menos uma aprovação na última iteração para exigir pelo menos um voto de aprovação para a última alteração de ramificação de origem.
Selecione Redefinir todos os votos de aprovação (não redefine votos para rejeitar ou esperar) para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou esperar, sempre que a ramificação de origem mudar.
Selecione Redefinir todos os votos do revisor de código para remover todos os votos do revisor sempre que a ramificação de origem for alterada, incluindo votos para aprovar, rejeitar ou aguardar.
Em Quando novas alterações são enviadas por push:
Selecione Exigir pelo menos uma aprovação em cada iteração para exigir pelo menos um voto de aprovação para a última alteração de ramificação de origem. A aprovação do usuário não é contada em relação a nenhuma iteração anterior não aprovada enviada por esse usuário. Como resultado, outra aprovação na última iteração é necessária para ser feita por outro usuário. Exigir pelo menos uma aprovação em cada iteração está disponível no Azure DevOps Server 2022.1 e superior.
Selecione Exigir pelo menos uma aprovação na última iteração para exigir pelo menos um voto de aprovação para a última alteração de ramificação de origem.
Selecione Redefinir todos os votos de aprovação (não redefine votos para rejeitar ou esperar) para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou esperar, sempre que a ramificação de origem mudar.
Selecione Redefinir todos os votos do revisor de código para remover todos os votos do revisor sempre que a ramificação de origem for alterada, incluindo votos para aprovar, rejeitar ou aguardar.
Se a opção Solicitantes puder aprovar suas próprias alterações não for selecionada, o criador da solicitação pull ainda poderá votar em Aprovar na solicitação pull, mas seu voto não contará para o Número mínimo de revisores.
Se algum revisor rejeitar as alterações, a solicitação pull não poderá ser concluída, a menos que você selecione Permitir conclusão, mesmo que alguns revisores votem para aguardar ou rejeitar.
Você pode redefinir os votos do revisor de código quando novas alterações são enviadas por push para a ramificação de origem. Selecione Redefinir votos do revisor de código quando houver novas alterações.
Se todas as outras políticas forem aprovadas, o criador poderá concluir a RP quando o número necessário de revisores aprová-la.
Bloqueie se a política não for cumprida. Valores aceites: false, true. Necessário.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main. Necessário.
creator-vote-counts
Conte o voto do criador. Valores aceites: false, true. Necessário.
enabled
Habilite a política. Valores aceites: false, true. Necessário.
minimum-approver-count
Número mínimo de aprovadores exigidos. Por exemplo: 2. Necessário.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Necessário.
reset-on-source-push
Redefina os votos quando as alterações forem enviadas para a fonte. Valores aceites: false, true. Necessário.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Exemplo
O exemplo a seguir define o número mínimo de aprovações necessárias para 2 solicitações pull na main ramificação do repositório da Fabrikam. A política permite downvotes, o que significa que os pedidos de pull podem ser concluídos mesmo que alguns revisores votem para não aprovar, desde que o número mínimo vote para aprovar. Pushes para a ramificação de origem não redefinem votos. A política também permite que os criadores de pull request aprovem suas próprias solicitações pull.
Este exemplo usa a configuração az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber"padrão .
az repos policy approver-count create --allow-downvotes true --blocking true --branch main --creator-vote-counts true --enabled true --minimum-approver-count 2 --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --reset-on-source-push false --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- --------------------------- ------------- ------------ ------------------------------------ ---------------
27 Minimum number of reviewers True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Bloqueie se a política não for cumprida. Valores aceites: false, true.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
creator-vote-counts
Conte o voto do criador. Valores aceites: false, true.
detect
Detete automaticamente a organização. Valores aceites: false, true.
enabled
Habilite a política. Valores aceites: false, true.
minimum-approver-count
Número mínimo de aprovadores exigidos. Por exemplo: 2.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
reset-on-source-push
Redefina os votos quando as alterações forem enviadas para a fonte. Valores aceites: false, true.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Os comandos da CLI do Azure DevOps não são suportados para o Servidor de DevOps do Azure.
Verificar itens de trabalho vinculados
Para o acompanhamento do gerenciamento de itens de trabalho, você pode exigir associações entre RPs e itens de trabalho. A vinculação de itens de trabalho fornece mais contexto para alterações e garante que as atualizações passem pelo processo de controle de itens de trabalho.
Para definir a política, em Políticas de Filial, defina Verificar itens de trabalho vinculados como Ativado. Essa configuração requer que os itens de trabalho sejam vinculados a uma RP para que a RP seja mesclada. Torne a configuração Opcional para avisar quando não houver itens de trabalho vinculados, mas permita a conclusão da solicitação pull.
Você pode usar a política de repositório az da CLI do Azure para criar e atualizar políticas de vinculação de item de trabalho para uma filial ou repositório.
Bloqueie se a política não for cumprida. Valores aceites: false, true. Necessário.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main. Necessário.
enabled
Habilite a política. Valores aceites: false, true. Necessário.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Atualizar a política de vinculação de item de trabalho
Bloqueie se a política não for cumprida. Valores aceites: false, true.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
enabled
Habilite a política. Valores aceites: false, true.
minimum-approver-count
Número mínimo de aprovadores exigidos. Por exemplo: 2.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Exemplo
O exemplo a seguir atualiza a ID 3 de política para que a main ramificação do repositório da Fabrikam seja habilitada, mas opcional. O exemplo usa a configuração az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber"padrão .
>az repos policy work-item-linking update --id 3 --blocking false --branch main --enabled true --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ----------------- ------------- ------------ ------------------------------------ ---------------
3 Work item linking False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Os comandos da CLI do Azure DevOps não são suportados para o Servidor de DevOps do Azure.
Verificar a resolução de comentários
A política Verificar se há resolução de comentários verifica se todos os comentários de RP foram resolvidos.
Configure uma política de resolução de comentários para sua ramificação definindo Verificar resolução de comentários como Ativado. Em seguida, selecione se deseja tornar a política Obrigatória ou Opcional.
Para obter mais informações sobre como trabalhar com comentários de solicitação pull, consulte Revisar solicitações pull.
Configure uma política de resolução de comentários para sua ramificação selecionando Verificar resolução de comentários.
Para obter mais informações sobre como trabalhar com comentários de solicitação pull, consulte Revisar solicitações pull.
Você pode usar a política de comentários az repos da CLI do Azure DevOps para definir e atualizar a política de resolução de comentários.
Bloqueie se a política não for cumprida. Valores aceites: false, true. Necessário.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main. Necessário.
enabled
Habilite a política. Valores aceites: false, true. Necessário.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Necessário.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Bloqueie se a política não for cumprida. Valores aceites: false, true.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
enabled
Habilite a política. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Exemplo
O exemplo a seguir atualiza o ID 6 da política de resolução de comentários na main ramificação do repositório da Fabrikam a ser bloqueado. Os comentários devem ser resolvidos antes que as solicitações pull possam ser mescladas. Este exemplo usa a configuração az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber"padrão .
az repos policy comment-required update --id 6 --blocking true --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- -------------------- ------------- ------------ ------------------------------------ ---------------
6 Comment requirements True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Os comandos da CLI do Azure DevOps não são suportados para o Servidor de DevOps do Azure.
Limitar tipos de mesclagem
O Azure Repos tem várias estratégias de mesclagem e, por padrão, todas elas são permitidas. Você pode manter um histórico de ramificação consistente impondo uma estratégia de mesclagem para conclusão de RP.
Bloqueie se a política não for cumprida. Valores aceites: false, true. Necessário.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main. Necessário.
enabled
Habilite a política. Valores aceites: false, true. Necessário.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Necessário.
allow-no-fast-forward
Mesclagem básica sem avanço rápido. Preserva a história não linear exatamente como aconteceu durante o desenvolvimento. Valores aceites: false, true.
allow-rebase
Rebaseie e avance rapidamente. Cria um histórico linear reproduzindo as confirmações de ramificação de origem no destino sem uma confirmação de mesclagem. Valores aceites: false, true.
allow-rebase-merge
Rebaseie com confirmação de mesclagem. Cria um histórico semilinear reproduzindo as confirmações de ramificação de origem no destino e, em seguida, criando uma confirmação de mesclagem. Valores aceites: false, true.
allow-squash
Fusão de squash. Cria um histórico linear condensando as confirmações de ramificação de origem em uma única nova confirmação na ramificação de destino. Valores aceites: false, true.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
use-squash-merge
Sempre squash mesclar. Esta opção não está disponível para outros tipos de mesclagem. Valores aceites: false, true.
Nota: use-squash-merge foi preterido e será removido em uma versão futura. Utilize --allow-squash em substituição.
Exemplo
O exemplo a seguir define uma estratégia de mesclagem necessária para solicitações pull na main ramificação do repositório da Fabrikam para permitir a mesclagem de squash. Este exemplo usa a configuração az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber"padrão .
az repos policy merge-strategy create --allow-squash true --blocking true --branch main --enabled true --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ------------------------ ------------- ------------ ------------------------------------ ---------------
29 Require a merge strategy True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Mesclagem básica sem avanço rápido. Preserva a história não linear exatamente como aconteceu durante o desenvolvimento. Valores aceites: false, true.
allow-rebase
Rebaseie e avance rapidamente. Cria um histórico linear reproduzindo as confirmações de ramificação de origem no destino sem uma confirmação de mesclagem. Valores aceites: false, true.
allow-rebase-merge
Rebaseie com confirmação de mesclagem. Cria um histórico semilinear reproduzindo as confirmações de ramificação de origem no destino e, em seguida, criando uma confirmação de mesclagem. Valores aceites: false, true.
allow-squash
Fusão de squash. Cria um histórico linear condensando as confirmações de ramificação de origem em uma única nova confirmação na ramificação de destino. Valores aceites: false, true.
blocking
Bloqueie se a política não for cumprida. Valores aceites: false, true.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
enabled
Habilite a política. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
use-squash-merge
Se o squash deve ser mesclado sempre. Essa opção não funciona para outros tipos de mesclagem. Valores aceites: false, true.
Os comandos da CLI do Azure DevOps não são suportados para o Servidor de DevOps do Azure.
Impor uma estratégia de mesclagem
Mantenha um histórico de ramificação consistente impondo uma estratégia de mesclagem quando uma solicitação pull for concluída.
Selecione Impor uma estratégia de mesclagem e escolha uma opção para exigir que as solicitações pull sejam mescladas usando essa estratégia.
Sem mesclagem rápida - Esta opção mescla o histórico de confirmação da ramificação de origem quando a solicitação pull é fechada e cria uma confirmação de mesclagem na ramificação de destino.
Mesclagem de squash - Conclua todas as solicitações pull com uma mesclagem de squash, criando uma única confirmação na ramificação de destino com as alterações da ramificação de origem. Saiba mais sobre a fusão de squash e como ela afeta o histórico do seu ramo.
Validação de compilação
Você pode definir uma política que exija que as alterações de RP sejam compiladas com êxito antes que a RP possa ser concluída.
Crie políticas, reduza as interrupções e mantenha os resultados do teste aprovados. As políticas de criação ajudam mesmo se você estiver usando a integração contínua (CI) em suas ramificações de desenvolvimento para detetar problemas antecipadamente.
Uma política de validação de compilação enfileira uma nova compilação quando uma nova RP é criada ou as alterações são enviadas por push para uma RP existente destinada à ramificação. A política de compilação avalia os resultados da compilação para determinar se a RP pode ser concluída.
Importante
Antes de especificar uma política de validação de compilação, você deve ter um pipeline de compilação. Se você não tiver um pipeline, consulte Criar um pipeline de compilação. Escolha o tipo de compilação que corresponde ao seu tipo de projeto.
Para adicionar uma política de validação de compilação
Selecione o + botão ao lado de Validação de compilação.
Preencha o formulário Definir política de compilação:
Selecione o pipeline Build.
Opcionalmente, defina um filtro de caminho. Saiba mais sobre filtros de caminho em políticas de filial.
Em Gatilho, selecione Automático (sempre que a ramificação de origem for atualizada) ou Manual.
Em Requisito de política, selecione Obrigatório ou Opcional. Se você escolher Obrigatório, as compilações deverão ser concluídas com êxito para concluir os PRs. Escolha Opcional para fornecer uma notificação da falha de compilação, mas ainda permitir que os PRs sejam concluídos.
Defina uma expiração de compilação para garantir que as atualizações para sua ramificação protegida não interrompam as alterações para PRs abertas.
Imediatamente quando <o nome> da ramificação é atualizado: esta opção define o status da política de compilação de RP como falhando sempre que a ramificação é atualizada e coloca novamente uma compilação na fila. Essa configuração garante que as alterações de RP sejam compiladas com êxito, mesmo que a ramificação protegida seja alterada.
Esta opção é melhor para equipas cujas ramificações importantes têm poucas alterações. As equipes que trabalham em ramificações de desenvolvimento ocupadas podem achar perturbador esperar por uma compilação toda vez que a ramificação for atualizada.
Após <n> horas se <o nome> da ramificação tiver sido atualizado: esta opção expira o status atual da política quando a ramificação protegida é atualizada se a compilação de passagem for mais antiga do que o limite inserido. Essa opção é um compromisso entre sempre ou nunca exigir uma compilação quando a ramificação protegida é atualizada. Essa opção reduz o número de compilações quando sua ramificação protegida tem atualizações frequentes.
Nunca: as atualizações da ramificação protegida não alteram o status da política. Esse valor reduz o número de compilações, mas pode causar problemas ao concluir PRs que não foram atualizadas recentemente.
Insira um Nome para exibição opcional para esta política de compilação. Esse nome identifica a política na página Políticas de filial . Se você não especificar um nome para exibição, a política usará o nome do pipeline de compilação.
Selecione Guardar.
Quando o proprietário de RP envia por push alterações que são compiladas com êxito, o status da política é atualizado.
Se você tiver uma política de compilação Imediatamente quando <o nome> da ramificação for atualizado ou Após <n> horas se <o nome> da filial tiver sido atualizado, o status da política será atualizado quando a ramificação protegida for atualizada, se a compilação anterior não for mais válida.
Nota
Esse recurso está disponível para o Azure DevOps Server 2020 e versões posteriores.
Você pode usar a compilação de política az repos da CLI do Azure DevOps para definir e atualizar a política de validação de compilação.
Bloqueie se a política não for cumprida. Valores aceites: false, true. Necessário.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main. Necessário.
build-definition-id
O ID de definição de compilação. Necessário.
display-name
Nome de exibição para esta política de compilação para identificar a política. Por exemplo: Manual queue policy. Necessário.
enabled
Habilite a política. Valores aceites: false, true. Necessário.
manual-queue-only
Se deve permitir apenas fila manual de compilações. Valores aceites: false, true. Necessário.
queue-on-source-update-only
Se as compilações de fila devem ser feitas somente quando a fonte for atualizada. Valores aceites: false, true. Necessário.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Necessário.
valid-duration
Duração da validade da apólice, em minutos. Nota:valid-duration deve ser entre zero e um ano, e deve ser zero quando --queue-on-source-update-only é false. Necessário.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
path-filter
O caminho no qual aplicar a política é aplicado. Suporta caminhos absolutos, curingas e vários caminhos separados por ;. Exemplos: /WebApp/Models/Data.cs, /WebApp/*, ou *.cs,/WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Exemplo
O exemplo a seguir define uma política de compilação necessária para solicitações pull na main ramificação do repositório da Fabrikam. A política requer uma compilação bem-sucedida da ID 1de definição de compilação e permite apenas o enfileiramento manual de compilação. Este exemplo usa a configuração az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber"padrão .
az repos policy build create --blocking true --branch main --build-definition-id 1 --display-name build-policy --enabled true --manual-queue-only true --queue-on-source-update-only false --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --valid-duration 0 --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ------------ ------------- ------------ ------------------------------------ ---------------
31 build-policy True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Bloqueie se a política não for cumprida. Valores aceites: false, true.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
build-definition-id
O ID de definição de compilação.
detect
Detete automaticamente a organização. Valores aceites: false, true.
display-name
Nome de exibição para esta política de compilação para identificar a política. Por exemplo: Manual queue policy.
enabled
Habilite a política. Valores aceites: false, true.
manual-queue-only
Se deve permitir apenas fila manual de compilações. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
path-filter
Os caminhos nos quais aplicar a política são aplicados. Suporta caminhos absolutos, curingas e vários caminhos separados por ;. Exemplos: /WebApp/Models/Data.cs, /WebApp/*, ou *.cs,/WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
queue-on-source-update-only
Se as compilações de fila devem ser feitas somente quando a fonte for atualizada. Valores aceites: false, true.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
valid-duration
Duração da validade da apólice, em minutos.
Os comandos da CLI do Azure DevOps não são suportados para o Servidor de DevOps do Azure.
Defina uma política que exija alterações em uma solicitação pull para construir com êxito com a ramificação protegida antes que a solicitação pull possa ser concluída.
Crie políticas, reduza as interrupções e mantenha os resultados do teste aprovados. As políticas de criação ajudam mesmo se você estiver usando a integração contínua (CI) em suas ramificações de desenvolvimento para detetar problemas antecipadamente.
Se uma política de validação de compilação estiver habilitada, uma nova compilação será enfileirada quando uma nova solicitação pull for criada ou quando as alterações forem enviadas por push para uma solicitação pull existente destinada à ramificação. Em seguida, a política de compilação avalia os resultados da compilação para determinar se a solicitação pull pode ser concluída.
Importante
Antes de especificar uma política de validação de compilação, você deve ter uma definição de compilação. Se você não tiver uma, consulte Criar uma definição de compilação e escolha o tipo de compilação que corresponde ao seu tipo de projeto.
Escolha Adicionar política de compilação e configure suas opções em Adicionar política de compilação.
Selecione a definição de compilação.
Escolha o tipo de gatilho. Selecione Automático (sempre que a ramificação de origem for atualizada) ou Manual.
Selecione o requisito Política. Se você escolher Obrigatório, as compilações deverão ser concluídas com êxito para concluir as solicitações pull. Escolha Opcional para fornecer uma notificação da falha de compilação, mas ainda permitir que as solicitações pull sejam concluídas.
Defina uma expiração de compilação para garantir que as atualizações para sua ramificação protegida não interrompam as alterações para solicitações pull abertas.
Imediatamente quando branch name é atualizado: esta opção define o status da política de compilação em uma solicitação pull como falha quando a ramificação protegida é atualizada. Enfileire novamente uma compilação para atualizar o status da compilação. Essa configuração garante que as alterações nas solicitações pull sejam criadas com êxito, mesmo quando a ramificação protegida é alterada. Esta opção é melhor para equipas que têm filiais importantes com um menor volume de alterações. As equipes que trabalham em ramificações de desenvolvimento ocupadas podem achar perturbador esperar que uma compilação seja concluída toda vez que a ramificação protegida for atualizada.
Após n o expediente, se branch name tiver sido atualizado: esta opção expira o status atual da política quando a ramificação protegida é atualizada se a compilação de passagem for mais antiga do que o limite inserido. Essa opção é um compromisso entre sempre exigir uma compilação quando a ramificação protegida é atualizada e nunca exigir uma. Essa opção é excelente para reduzir o número de compilações quando sua ramificação protegida tem atualizações frequentes.
Nunca: as atualizações da ramificação protegida não alteram o status da política. Esse valor reduz o número de compilações para sua ramificação. Pode causar problemas ao fechar solicitações pull que não foram atualizadas recentemente.
Insira um Nome para exibição opcional para esta política de compilação. Esse nome identifica a política na página Políticas de filial . Se você não especificar um nome para exibição, a política usará o nome da definição de compilação.
Selecione Guardar.
Quando o proprietário envia por push alterações que são compiladas com êxito, o status da política é atualizado. Se você tiver uma política de compilação Imediatamente quando branch name for atualizada ou Após n horas se branch name tiver sido atualizada a política escolhida, o status da política será atualizado quando a ramificação protegida for atualizada se a compilação mais recente não for mais válida.
Verificações de status
Os serviços externos podem usar a API de status de RP para postar status detalhado em seus RPs. A política de filial para serviços adicionais permite que esses serviços externos participem do fluxo de trabalho de RP e estabeleçam requisitos de política.
Os serviços externos podem usar a API de status de RP para postar status detalhado em seus RPs. A política de filiais para serviços adicionais traz a capacidade desses serviços externos de participar do fluxo de trabalho de RP e estabelecer requisitos de política.
Você pode adicionar automaticamente revisores para receber solicitações que alteram arquivos em diretórios e arquivos específicos ou para todas as solicitações pull em um repositório.
Selecione o + botão ao lado de Revisores incluídos automaticamente.
Preencha a tela Adicionar nova política de revisor.
Adicione pessoas e grupos aos Revisores.
Selecione Opcional se quiser adicionar revisores automaticamente, mas não exigir a aprovação deles para concluir a solicitação pull.
Ou selecione Obrigatório se as solicitações pull não puderem ser concluídas até:
Cada indivíduo adicionado como revisor aprova as alterações.
Pelo menos uma pessoa em cada grupo adicionado como revisor aprova as alterações.
Se apenas um grupo for necessário, o número mínimo de membros especificado aprovará as alterações.
Especifique os arquivos e pastas que exigem os revisores incluídos automaticamente. Deixe este campo em branco para exigir que os revisores para todas as solicitações pull na ramificação.
Selecione Permitir que os solicitantes aprovem suas próprias alterações se os proprietários da solicitação pull puderem votar para aprovar suas próprias solicitações pull para atender a esta política.
Você pode especificar uma mensagem do feed de atividades que aparece na solicitação pull.
Selecione Guardar.
Nota
Esse recurso está disponível para o Azure DevOps Server 2020 e versões posteriores.
Você pode usar a política required-reviewer da CLI az repos do Azure DevOps para definir e atualizar a política de revisor necessária.
Bloqueie se a política não for cumprida. Valores aceites: false, true. Necessário.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main. Necessário.
enabled
Habilite a política. Valores aceites: false, true. Necessário.
message
Mensagem do feed de atividades que aparece na solicitação pull. Necessário.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Necessário.
required-reviewer-ids
Endereços de e-mail do revisor separados por ;. Por exemplo: john@contoso.com;alice@contoso.com.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
path-filter
Os caminhos nos quais aplicar a política são aplicados. Suporta caminhos absolutos, curingas e vários caminhos separados por ;. Exemplos: /WebApp/Models/Data.cs, /WebApp/*, ou *.cs,/WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Exemplo
O exemplo a seguir define Jamal Hartnett como um revisor necessário para solicitações pull na main ramificação do repositório da Fabrikam. Este exemplo usa a configuração az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber"padrão .
az repos policy required-reviewer create --blocking true --branch main --enabled true --message "Please review." --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --required-reviewer-ids fabrikamfiber4@hotmail.com --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ------------------ ------------- ------------ ------------------------------------ ---------------
35 Required reviewers True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Bloqueie se a política não for cumprida. Valores aceites: false, true.
branch
Nome da ramificação para filtrar os resultados por correspondência exata. O --repository-id parâmetro é necessário para usar o filtro de ramificação. Por exemplo: --branch main.
branch-match-type
Use o branch argumento para aplicar a política. Se o valor for exact, a política será aplicada em uma ramificação que corresponda exatamente ao --branch argumento. Se o valor for prefix, a política se aplicará a todas as pastas de ramificação que correspondem ao --branch prefixo no argumento. Valores aceites: exact, prefix. Valor predefinido: exact.
detect
Detete automaticamente a organização. Valores aceites: false, true.
enabled
Habilite a política. Valores aceites: false, true.
message
Mensagem do feed de atividades que aparece na solicitação pull.
org
URL da organização do Azure DevOps. Você pode configurar a organização padrão usando az devops configure -d organization=<ORG_URL>. Necessário se não configurado como padrão ou captado via git config. Exemplo: https://dev.azure.com/MyOrganizationName/.
path-filter
Os caminhos nos quais aplicar a política são aplicados. Suporta caminhos absolutos, curingas e vários caminhos separados por ;. Exemplos: /WebApp/Models/Data.cs, /WebApp/*, ou *.cs,/WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nome ou ID do projeto. Você pode configurar o projeto padrão usando az devops configure -d project=<NAME_OR_ID>. Necessário se não configurado como padrão ou captado via git config.
repository-id
ID do repositório para filtrar os resultados por correspondência exata. Por exemplo, --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
required-reviewer-ids
Endereços de e-mail do revisor separados por ;. Por exemplo: john@contoso.com;alice@contoso.com.
subscription
o nome ou o ID da subscrição. Você pode configurar a assinatura padrão usando az account set -s <NAME_OR_ID>o .
Os comandos da CLI do Azure DevOps não são suportados para o Servidor de DevOps do Azure.
Selecione revisores para diretórios e arquivos específicos em seu repositório.
Esses revisores são adicionados automaticamente para receber solicitações que alteram arquivos ao longo desses caminhos. Você também pode especificar uma mensagem do feed de atividades.
Se você selecionar Obrigatório, a solicitação pull não poderá ser concluída até:
Cada usuário adicionado como revisor para o caminho aprova as alterações.
Pelo menos uma pessoa em cada grupo adicionado ao caminho aprova as mudanças.
O número de revisores especificado para cada grupo adicionado ao caminho aprova as alterações.
Selecione Opcional se quiser adicionar revisores automaticamente, mas não exigir a aprovação deles para concluir a solicitação pull.
Você pode selecionar Os solicitantes podem aprovar suas próprias alterações.
Quando todos os revisores necessários aprovarem o código, você poderá concluir a solicitação pull.
Ignorar políticas de ramificação
Em alguns casos, talvez seja necessário ignorar os requisitos da política. As permissões de bypass permitem que você envie alterações diretamente para uma ramificação ou conclua solicitações pull que não satisfaçam as políticas de ramificação. Você pode conceder permissões de bypass a um usuário ou grupo. Você pode definir o escopo de permissões de bypass para um projeto inteiro, um repositório ou uma única ramificação.
Duas permissões permitem que os usuários ignorem a política de ramificação de maneiras diferentes:
As políticas de bypass ao concluir solicitações pull se aplicam apenas à conclusão da solicitação pull. Os usuários com essa permissão podem concluir solicitações pull mesmo que as solicitações pull não satisfaçam as políticas.
As políticas de bypass ao enviar por push se aplicam a pushes de repositórios locais e edições feitas na Web. Os usuários com essa permissão podem enviar as alterações diretamente para filiais protegidas sem atender aos requisitos da política.
Para obter mais informações sobre como gerenciar essas permissões, consulte Permissões do Git.
No TFS 2015 até a Atualização 2 do TFS 2018, a permissão Isentar da imposição de política permite que os usuários com essa permissão executem as seguintes ações:
Opte por substituir políticas e concluir uma solicitação pull mesmo que o conjunto atual de políticas de filial não esteja satisfeito.
Envie diretamente para uma ramificação, mesmo que essa ramificação tenha políticas de ramificação definidas. Quando um usuário com essa permissão faz um push que substituiria a política de ramificação, o push ignora automaticamente a política de ramificação sem nenhuma etapa de aceitação ou aviso.
Importante
Tenha cuidado ao conceder a capacidade de ignorar políticas, especialmente nos níveis de recompra e projeto. As políticas são a pedra angular do gerenciamento seguro e compatível do código-fonte.
Filtros de caminho
Várias políticas de ramificação oferecem filtros de caminho. Se um filtro de caminho for definido, a política se aplicará somente a arquivos que correspondam ao filtro de caminho. Deixar esse campo em branco significa que a política se aplica a todos os arquivos na ramificação.
Você pode especificar caminhos absolutos (caminho deve começar por / ou um curinga) e curingas.
Exemplos:
/WebApp/Models/Data.cs
/WebApp/*
*/Models/Data.cs
*.cs
Você pode especificar vários caminhos usando ; como separador.
Exemplo:
/WebApp/Models/Data.cs;/ClientApp/Models/Data.cs
Os caminhos prefixados com ! são excluídos se de outra forma seriam incluídos.
Exemplo:
/WebApp/*;!/WebApp/Tests/* inclui todos os arquivos, /WebApp exceto arquivos em /WebApp/Tests
!/WebApp/Tests/* não especifica nenhum arquivo, uma vez que nada é incluído primeiro
A ordem dos filtros é significativa. Os filtros são aplicados da esquerda para a direita.
Posso enviar alterações diretamente para filiais que têm políticas de filiais?
Não é possível enviar alterações diretamente para filiais com políticas de ramificação necessárias, a menos que tenha permissões para ignorar políticas de ramificação. As alterações nessas ramificações só podem ser feitas por meio de solicitações pull. Você pode enviar as alterações diretamente para ramificações que tenham políticas de ramificação opcionais , se elas não tiverem políticas de ramificação necessárias.
O que é o preenchimento automático?
Receber solicitações em ramificações com políticas de ramificação configuradas tem o botão Definir preenchimento automático. Selecione esta opção para concluir automaticamente a solicitação pull assim que ela cumprir todas as políticas. O preenchimento automático é útil quando você não espera problemas com suas alterações.
Quando são verificadas as condições da política da sucursal?
As políticas de filial são reavaliadas no servidor quando os proprietários da solicitação pull enviam alterações e quando os revisores votam. Se uma política acionar uma compilação, o status da compilação será definido como aguardando até que a compilação seja concluída.
Posso usar definições de compilação XAML em políticas de ramificação?
Não, você não pode usar definições de compilação XAML em políticas de ramificação.
Que caracteres curinga posso usar para revisores de código necessários?
Os asteriscos * únicos correspondem a qualquer número de caracteres, incluindo barras / para a frente e barras \para trás. Os pontos ? de interrogação correspondem a qualquer caractere.
Exemplos:
*.sql Corresponde a todos os arquivos com a extensão .sql .
/ConsoleApplication/* corresponde a todos os arquivos na pasta chamada ConsoleApplication.
/.gitattributes corresponde ao arquivo .gitattributes* na raiz do repo.
*/.gitignore Corresponde a qualquer arquivo .gitignore no repositório.
Os caminhos do revisor de código necessários diferenciam maiúsculas de minúsculas?
Não, as políticas de filial não diferenciam maiúsculas de minúsculas.
Como posso configurar vários usuários como revisores necessários, mas exigir que apenas um deles aprove?
Você pode adicionar os usuários a um grupo e, em seguida, adicionar o grupo como um revisor. Qualquer membro do grupo pode então aprovar para atender ao requisito da política.
Tenho permissões de política de bypass. Por que ainda vejo falhas de política no status da solicitação pull?
As políticas configuradas são sempre avaliadas quanto a alterações de solicitação pull. Para usuários que têm permissões de política de bypass, o status da política relatada é apenas consultivo. Se o usuário com permissões de bypass aprovar, o status de falha não bloqueará a conclusão da solicitação pull.
Por que não consigo concluir minhas próprias solicitações pull quando "Permitir que os solicitantes aprovem suas próprias alterações está definido"?
Tanto a política Exigir um número mínimo de revisores quanto a política Revisores incluídos automaticamente têm opções para Permitir que os solicitantes aprovem suas próprias alterações. Em cada política, a configuração se aplica somente a essa política. A configuração não afeta a outra política.
Por exemplo, sua solicitação pull tem as seguintes políticas definidas:
Exigir um número mínimo de revisores requer pelo menos um avaliador.
Os revisores incluídos automaticamente exigem que você ou uma equipe na qual você esteja como revisor.
Os revisores incluídos automaticamente habilitaram Permitir que os solicitantes aprovem suas próprias alterações .
Exigir um número mínimo de revisores não tem Permitir que os solicitantes aprovem suas próprias alterações habilitado.
Nesse caso, sua aprovação satisfaz os revisores incluídos automaticamente, mas não Exige um número mínimo de revisores, portanto, você não pode concluir a solicitação pull.
Também pode haver outras políticas, como Proibir o empurrador mais recente de aprovar suas próprias alterações, que impedem que você aprove suas próprias alterações, mesmo que Permitir que os solicitantes aprovem suas próprias alterações esteja definido.
O que acontece quando o caminho nos filtros de caminho não começa com / ou com um curinga?
O caminho nos filtros de caminho que não começa com / ou com um curinga não tem efeito e o filtro de caminho é avaliado como se esse caminho não tivesse sido especificado. Esse caminho não pode corresponder ao / caminho absoluto do arquivo com o qual começa.
