Partilhar via

Políticas e definições de ramos

  • Artigo

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.

Configurar políticas de filial

Para gerenciar políticas de filial, selecione Repos>Branches para abrir a página Branches no portal da Web.

Captura de tela que mostra o item de menu Ramos.

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.

Captura de tela que mostra Abrir as 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.

Captura de tela que mostra a página Ramos.

Selecione o botão ... . Selecione Políticas de ramificação no menu de contexto.

Captura de tela que mostra Abrir as 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.

Captura de ecrã que mostra o separador Políticas.

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:

Captura de tela que mostra a política Ativar a política Exigir revisões de código.

  • 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.

Marque a caixa Exigir revisões de código

  • 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.

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.

Captura de tela mostrando a necessidade de itens de trabalho vinculados em solicitações pull.

Exigir itens de trabalho vinculados em suas solicitações pull

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.

Captura de ecrã de Verificar a 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.

Configure uma política de resolução de comentários para sua ramificação selecionando Verificar resolução de comentários.

Verificar a 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.

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.

Defina Limitar tipos de mesclagem como Ativado para limitar quais tipos de mesclagem devem ser permitidos em seu repositório.

Captura de tela de Limitar tipos de mesclagem.

  • A mesclagem básica (sem avanço rápido) cria uma confirmação de mesclagem no destino cujos pais são as ramificações de destino e de origem.
  • A mesclagem de squash cria um histórico linear com 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 ramo.
  • Rebasear e avançar rapidamente cria um histórico linear reproduzindo confirmações de origem na ramificação de destino sem confirmação de mesclagem.
  • Rebasear com confirmação de mesclagem reproduz a fonte confirma no destino e também cria uma confirmação de mesclagem.

Nota

Esse recurso está disponível para o Azure DevOps Server 2020 e versões posteriores.

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.

Definir requisitos de mesclagem

  • 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

  1. Selecione o + botão ao lado de Validação de compilação.

    Captura de tela que mostra o botão Adicionar ao lado de Validação de compilação.

  2. Preencha o formulário Definir política de compilação:

    Captura de ecrã de Definições de 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.

  3. 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.

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.

Adicionar política de compilação

Escolha Adicionar política de compilação e configure suas opções em Adicionar política de compilação.

Criar configurações de política

  1. Selecione a definição de compilação.

  2. Escolha o tipo de gatilho. Selecione Automático (sempre que a ramificação de origem for atualizada) ou Manual.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Captura de ecrã de Exigir a aprovação de serviços externos.

Para obter instruções sobre como configurar essa política, consulte Configurar uma política de ramificação para um serviço externo.

Requer aprovação de serviços externos

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.

Exigir a aprovação de serviços externos

Para obter instruções sobre como configurar essa política, consulte Configurar uma política de ramificação para um serviço externo.

Incluir automaticamente revisores de código

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.

  1. Selecione o + botão ao lado de Revisores incluídos automaticamente.

    Captura de tela que mostra Adicionar revisores necessários.

  2. Preencha a tela Adicionar nova política de revisor.

    Captura de tela que mostra 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.

  3. Selecione Guardar.

Nota

Esse recurso está disponível para o Azure DevOps Server 2020 e versões posteriores.

Selecione revisores para diretórios e arquivos específicos em seu repositório.

Insira o caminho e os revisores necessários

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.

Adicionar revisores automáticos

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.

Os revisores necessários são adicionados automaticamente

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.

O status da solicitação pull mostra que os revisores aprovaram

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.

Captura de tela mostrando permissões de imposição de política de ignoramento.

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.

Perguntas e Respostas

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.