Compartilhar via

Políticas e configurações de branch

  • Artigo

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

As políticas de branch ajudam as equipes a proteger seus importantes branches de desenvolvimento. As políticas impõem a qualidade de código e os padrões de gerenciamento de alterações da sua equipe. Este artigo descreve como definir e gerenciar políticas de branch. Para obter uma visão geral de todas as políticas e configurações dos repositórios e branches, consulte Configurações e políticas do repositório Git.

Um branch com as políticas necessárias configuradas não pode ser excluída e requer PRs (solicitações de pull) para todas as alterações.

Pré-requisitos

  • Para definir políticas de branch, você deve ser membro do grupo de segurança Administradores do Projeto ou ter permissões de políticas de Edição no nível do repositório. Para obter mais informações, consulte Definir permissões do Repositório do Git.

Configurar políticas de branch

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

Captura de tela que mostra o item de menu Branches.

Você também pode acessar as configurações de política de branch com o Configurações de Projeto> Políticas>de Repositório > Política do Branch ><Nome Branch>.

Branches 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 do branch.

Para definir políticas de branch, localize o branch que você deseja gerenciar. Você pode navegar pela lista ou pesquisar sua branch na caixa de Pesquisar o nome da branch no canto superior direito.

Selecione o ícone Mais opções ao lado do branch e selecione políticas de branch no menu de contexto.

Captura de tela que mostra Abrir as políticas de branch no menu de contexto.

Localize seu branch na página. Você pode navegar pela lista ou pesquisar seu branch usando a caixa Pesquisar todos os branches no canto superior direito.

Captura de tela que mostra a página Branches.

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

Captura de tela que mostra Abrir as políticas de branch no menu de contexto.

Configure políticas na página de configurações do branch. 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 tela que mostra a guia 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 revisem e aprovem PRs, você pode exigir aprovação de um número mínimo de revisores. A política básica exige que um número especificado de revisores aprove o código, sem rejeições.

Para definir a política, em Políticas de Branch, defina Exigir um número mínimo de revisores como Ativado. Insira o número necessário de revisores e selecione qualquer uma das seguintes opções:

Captura de tela que mostra a política Habilitar 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 relações públicas vote em sua aprovação. Caso contrário, o criador ainda poderá votar Aprovar a PR, mas seu voto não contará para o número mínimo de revisores.

  • Selecione Proibir que o pusher mais recente aprove suas próprias alterações para impor a segregação de direitos. Por padrão, qualquer pessoa com permissão push no branch de origem pode adicionar commits e votar na aprovação de PR. Selecionar essa opção significa que o voto do pusher mais recente não conta, mesmo que eles possam normalmente aprovar suas próprias alterações.

  • Selecione Permitir conclusão mesmo se alguns revisores votarem para aguardar ou rejeitar para permitir a conclusão da PR, mesmo que alguns revisores votem contra a aprovação. O número mínimo de revisores ainda deve aprovar.

  • 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 do branch de origem.
    • Selecione Redefinir todos os votos de aprovação (não redefine votos para rejeitar ou aguardar) para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou aguardar, sempre que o branch de origem mudar
    • Selecione Redefinir todos os votos do revisor de código para remover todos os votos do revisor sempre que o branch de origem for alterado, 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 do branch de origem. A aprovação do usuário não é considerada em relação a nenhuma iteração anterior não aprovada enviada por ele. Como resultado, outra aprovação da última iteração deve ser feita por outro usuário. O recurso Exigir pelo menos uma aprovação em cada iteração está disponível no Azure DevOps Server 2022.1 e versões superiores.
    • 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 do branch de origem.
    • Selecione Redefinir todos os votos de aprovação (não redefine votos para rejeitar ou aguardar) para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou aguardar, sempre que o branch de origem mudar
    • Selecione Redefinir todos os votos do revisor de código para remover todos os votos do revisor sempre que o branch de origem for alterado, incluindo votos para aprovar, rejeitar ou aguardar.

Marque a caixa Exigir Revisões de Código

  • Se os Solicitantes puderem aprovar suas próprias alterações não estiverem selecionados, o criador da solicitação de pull ainda poderá votar Aprovar em sua solicitação de pull, mas seu voto não contará para o número mínimo de revisores.
  • Se qualquer revisor rejeitar as alterações, a solicitação de 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 forem enviadas por push para o branch 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 PR quando o número necessário de revisores a aprovar.

Verificar se há itens de trabalho vinculados

Para o acompanhamento de gerenciamento de itens de trabalho, você pode exigir associações entre PRs 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 acompanhamento do item de trabalho.

Para definir a política, em Políticas de Branch, defina Verificar se há itens de trabalho vinculados como Ativados. Essa configuração exige que os itens de trabalho sejam vinculados a uma PR para que a PR mescle. Torne a configuração Opcional para avisar quando não há itens de trabalho vinculados, mas permitir a conclusão da solicitação de pull.

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

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

Verificar a resolução de comentários

A política Verificar se a resolução de comentários verifica se todos os comentários de PR foram resolvidos.

Configure uma política de resolução de comentários para seu branch definindo Verificar se há resolução de comentários como Ativada. Em seguida, selecione se deseja tornar a política Necessária ou opcional.

Captura de tela de Verificar resolução de comentários.

Para obter mais informações sobre como trabalhar com comentários de solicitação de pull, consulte Examinar solicitações de pull.

Configure uma política de resolução de comentários para seu branch selecionando Verificar se há 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 de pull, consulte Examinar solicitações de 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 branch consistente impondo uma estratégia de mesclagem para conclusão de PR.

Defina o Limite de tipos de mesclagem como Ativado para limitar quais tipos de mesclagem permitir 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 os branches de destino e de origem.
  • A mesclagem squash cria um histórico linear com uma única confirmação no branch de destino com as alterações do branch de origem. Saiba mais sobre a mesclagem squash e como ela afeta o histórico de ramificações.
  • Trocar base e encaminhar criam um histórico linear reproduzindo commits de origem no branch de destino sem confirmação de mesclagem.
  • Trocar base com mesclagem commit repete as commits de origem no destino e também cria uma confirmação de mesclagem.

Observação

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 branch consistente impondo uma estratégia de mesclagem quando uma solicitação de pull for concluída. Selecione Impor uma estratégia de mesclagem e escolha uma opção para exigir a mesclagem de solicitações de pull usando essa estratégia.

Definir requisitos de mesclagem

  • Nenhuma mesclagem de encaminhar – essa opção mescla o histórico de confirmação do branch de origem quando a solicitação de pull é fechada e cria uma confirmação de mesclagem no branch de destino.
  • Mesclagem squash – conclua todas as solicitações de pull com uma mesclagem squash, criando uma única confirmação no branch de destino com as alterações do branch de origem. Saiba mais sobre a mesclagem squash e como ela afeta o histórico do branch.

Validação de build

Você pode definir uma política que exige que as alterações de PR sejam criadas com êxito antes que a PR possa ser concluída. As políticas de build reduzem as quebras e mantêm os resultados do teste aprovados. As políticas de build ajudam mesmo se você estiver usando a integração contínua (CI) em seus branches de desenvolvimento para detectar problemas antecipadamente.

Uma política de validação de build enfileira um novo build quando uma nova PR é criada ou as alterações são enviadas por push para uma PR existente que tem como destino o branch. A política de build avalia os resultados do build para determinar se a PR pode ser concluída.

Importante

Antes de especificar uma política de validação de build, você deve ter um pipeline de build. Se você não tiver um pipeline, consulte Criar um pipeline de build. Escolha o tipo de build que corresponde ao tipo de projeto.

Para adicionar uma política de validação de build

  1. Selecione o + botão ao lado da validação de build.

    Captura de tela que mostra o botão Adicionar ao lado da validação de build.

  2. Preencha o formulário Definir política de build:

    Captura de tela de Criar configurações de política.

    • Selecionar o pipeline de build.

    • Opcionalmente, defina um filtro Path. Saiba mais sobre filtros de caminho em políticas de branch.

    • Em Gatilho, selecione Automático (sempre que o branch de origem for atualizado) ou Manual.

    • Sob o requisito de política, selecione Obrigatório ou Opcional. Se você escolher Obrigatório, os builds deverão ser concluídos com êxito para concluir PRs. Escolha Opcional para fornecer uma notificação da falha de build, mas ainda permitir que as PRs preencham.

    • Defina um vencimento de build para garantir que as atualizações no branch protegido não interrompa as alterações para PRs abertas.

      • Imediatamente quando o <nome do branch> é atualizado: essa opção define o status da política de build de PR para falha sempre que o branch é atualizado e reenfileira um build. Essa configuração garante que as alterações de PR sejam compiladas com êxito mesmo se o branch protegido for alterado.

        Essa opção é melhor para equipes cujos branches importantes têm poucas alterações. As equipes que trabalham em branches de desenvolvimento ocupadas podem achar perturbador esperar por um build sempre que o branch for atualizado.

      • Após <n> horas, se <o nome do branch> tiver sido atualizado: essa opção expirará o status da política atual quando o branch protegido for atualizado se o build de passagem for mais antigo do que o limite inserido. Essa opção é um compromisso entre sempre ou nunca exigir um build quando o branch protegido é atualizado. Essa opção reduz o número de builds quando o branch protegido tem atualizações frequentes.

      • Nunca: as atualizações para o branch protegido não alteram o status da política. Esse valor reduz o número de builds, mas pode causar problemas ao concluir PRs que não foram atualizados recentemente.

    • Insira um nome de exibição opcional para essa política de build. Esse nome identifica a política na página de políticas do Branch. Se você não especificar um nome de exibição, a política usará o nome do pipeline de build.

  3. Clique em Salvar.

Quando o proprietário da PR envia por push as alterações que são compilá-las com êxito, o status da política é atualizado.

Se você tiver um Imediatamente quando <nome de branch> for atualizado ou Após <n> horas se o <nome do branch> tiver sido atualizado, o status da política será atualizado quando o branch protegido for atualizado, se o build anterior não for mais válido.

Observação

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

Defina uma política que exige alterações em uma solicitação de pull para compilar com êxito com o branch protegido antes que a solicitação de pull possa ser concluída. As políticas de build reduzem as quebras e mantêm os resultados do teste aprovados. As políticas de build ajudam mesmo se você estiver usando a integração contínua (CI) em seus branches de desenvolvimento para detectar problemas antecipadamente.

Se uma política de validação de build estiver habilitada, um novo build será enfileirado quando uma nova solicitação de pull for criada ou quando as alterações forem enviadas por push para uma solicitação de pull existente direcionada ao branch. Em seguida, a política de build avalia os resultados do build para determinar se a solicitação de pull pode ser concluída.

Importante

Antes de especificar uma política de validação de build, você deve ter uma definição de build. Se você não tiver uma, consulte Criar uma definição de build e escolha o tipo de build que corresponde ao tipo de projeto.

Adicionar política de build

Escolha Adicionar política de build e configure suas opções em Adicionar política de build.

Configurações de política de build

  1. Selecione a definição de Build.

  2. Escolha o tipo de Gatilho. Selecione Automático (sempre que o branch de origem for atualizado) ou Manual.

  3. Selecione o requisito de Política. Se você escolher Obrigatório, os builds deverão ser concluídos com êxito para concluir as solicitações de pull. Escolha Opcional para fornecer uma notificação da falha de build, mas ainda permitir a conclusão das solicitações de pull.

  4. Defina uma expiração de build para garantir que as atualizações do branch protegido não interrompa as alterações para solicitações de pull abertas.

    • Imediatamente quando branch name é atualizada: essa opção define o status da política de build em uma solicitação de pull para falha quando o branch protegido é atualizado. Reenfileirar um build para atualizar o status de build. Essa configuração garante que as alterações nas solicitações de pull sejam compiladas com êxito, mesmo quando o branch protegido é alterado. Essa opção é melhor para equipes que têm branches importantes com um volume menor de alterações. As equipes que trabalham em branches de desenvolvimento ocupados podem achar perturbador esperar que um build seja concluído sempre que o branch protegido for atualizado.
    • Após n horas, se branch name tiver sido atualizado: essa opção expirará o status da política atual quando o branch protegido for atualizado se o build de passagem for mais antigo do que o limite inserido. Essa opção é um compromisso entre sempre exigir um build quando o branch protegido é atualizado e nunca exigir um. Essa opção é excelente para reduzir o número de builds quando seu branch protegido tem atualizações frequentes.
    • Nunca: as atualizações para o branch protegido não alteram o status da política. Esse valor reduz o número de builds para o branch. Pode causar problemas ao fechar solicitações de pull que não eram atualizadas recentemente.

  5. Insira um nome de exibição opcional para essa política de build. Esse nome identifica a política na página de políticas do Branch. Se você não especificar um nome de exibição, a política usará o nome de definição de build.

  6. Clique em Salvar.

Quando o proprietário envia por push as alterações que são criadas com êxito, o status da política é atualizado. Se você tiver um Imediatamente quando branch name for atualizado ou Depois de n horas se branch name atualizou a política de build escolhida, o status da política é atualizado quando a branch protegida é atualizada se a build mais recente não for mais válida.

Verificações de status

Os serviços externos podem usar a API de Status de PR para postar o status detalhado em suas PRs. A política de branch para serviços adicionais permite que esses serviços externos participem do fluxo de trabalho de PR e estabeleçam requisitos de política.

Captura de tela de Exigir aprovação de serviços externos.

Para obter instruções sobre como configurar essa política, consulte Configurar uma política de branch para um serviçoexterno.

Exigir aprovação de serviços externos

Os serviços externos podem usar a API de Status de PR para postar o status detalhado em suas PRs. A política de branch para serviços adicionais possibilita que esses serviços externos participem do fluxo de trabalho de PR e estabeleçam requisitos de política.

Exigir que os serviços externos aprovem

Para obter instruções sobre como configurar essa política, consulte Configurar uma política de branch para um serviçoexterno.

Inclua revisores de código automaticamente

Você pode adicionar revisores automaticamente a solicitações de pull que alteram arquivos em diretórios e arquivos específicos ou a todas as solicitações de 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 você quiser adicionar revisores automaticamente, mas não exigir sua aprovação para concluir a solicitação de pull.

      Ou selecione Obrigatório se as solicitações de 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 que você especificar aprovará as alterações.

    • Especifique os arquivos e pastas que exigem os revisores incluídos automaticamente. Deixe esse campo em branco para exigir os revisores para todas as solicitações de pull no branch.

    • Selecione Permitir que os solicitantes aprovem suas próprias alterações se os proprietários da solicitação de pull puderem votar para aprovar suas próprias solicitações de pull para atender a essa política.

    • Você pode especificar uma mensagem do feed de atividades que aparece na solicitação de pull.

  3. Clique em Salvar.

Observação

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 a solicitações de pull que alteram arquivos ao longo desses caminhos. Você também pode especificar uma mensagem de feed de atividades.

Adicionar revisores automáticos

Se você selecionar Obrigatório, a solicitação de pull não poderá ser concluída até:

  • Cada usuário adicionado como revisor do caminho aprova as alterações.
  • Pelo menos uma pessoa em cada grupo adicionado ao caminho aprova as alterações.
  • O número de revisores especificados para cada grupo adicionado ao caminho aprova as alterações.

Revisores necessários são adicionados automaticamente

Selecione Opcional se você quiser adicionar revisores automaticamente, mas não exigir sua aprovação para concluir a solicitação de pull.

Você pode selecionar solicitantes que podem aprovar suas próprias alterações.

Quando todos os revisores necessários aprovarem o código, você poderá concluir a solicitação de pull.

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

Ignorar políticas de branch

Em alguns casos, talvez seja necessário ignorar os requisitos de política. As permissões de bypass permitem enviar alterações por push diretamente a um branch ou concluir solicitações de pull que não atendem às políticas de branch. 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 um único branch.

Duas permissões permitem que os usuários ignorem a política de branch de maneiras diferentes:

  • Ignorar políticas ao concluir solicitações de pull se aplica apenas à conclusão da solicitação de pull. Os usuários com essa permissão podem concluir solicitações de pull mesmo que as solicitações de pull não atendam às políticas.

  • Ignorar políticas ao enviar por push aplica-se a pushes de repositórios locais e edições feitas na Web. Os usuários com essa permissão podem enviar alterações diretamente para branches protegidos sem atender aos requisitos de política.

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

Para obter mais informações sobre como gerenciar essas permissões, consulte as permissões do Git.

No TFS 2015 até o TFS 2018 Atualização 2, a permissão Isenta de imposição de política permite que os usuários com essa permissão executem as seguintes ações:

  • Aceite substituir as políticas e conclua uma solicitação de pull mesmo se o conjunto atual de políticas de branch não estiver satisfeito.
  • Envie por push diretamente para um branch mesmo que esse branch tenha políticas de branch definidas. Quando um usuário com essa permissão faz um push que substituiria a política de branch, o push ignora automaticamente a política de branch sem nenhuma etapa ou aviso de aceitação.

Importante

Tenha cuidado ao conceder a capacidade de ignorar políticas, especialmente nos níveis de repositório e projeto. As políticas são uma base do gerenciamento de código-fonte seguro e compatível.

Filtros de caminho

Várias políticas de branch oferecem filtros de caminho. Se um filtro de caminho for definido, a política se aplicará somente aos arquivos que correspondem ao filtro de caminho. Deixar esse campo em branco significa que a política se aplica a todos os arquivos no branch.

Você pode especificar caminhos absolutos (o caminho deve começar por / ou um caractere curinga) e caractere curinga. 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 ! serão excluídos se forem incluídos de outra forma. Exemplo:

  • /WebApp/*;!/WebApp/Tests/* inclui todos os arquivos, /WebApp exceto arquivos em /WebApp/Tests
  • !/WebApp/Tests/* especifica nenhum arquivo, já que nada está 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 branches que têm políticas de branch?

Você não pode enviar alterações por push diretamente para branches com políticas de branch necessárias, a menos que você tenha permissões para ignorar as políticas de branch. As alterações nesses branches só podem ser feitas por meio de solicitações de pull. Você pode enviar alterações por push diretamente para branches que têm políticas de branch opcionais , se elas não tiverem políticas de branch necessárias.

O que é preenchimento automático?

Solicitações de pull em branches com políticas de branch configuradas têm o botão Definir preenchimento automático. Selecione essa opção para concluir automaticamente a solicitação de pull assim que ela atender a todas as políticas. O preenchimento automático é útil quando você não espera problemas com suas alterações.

Quando as condições da política de branch são verificadas?

As políticas de branch são reavaliadas no servidor quando os proprietários da solicitação de pull pressionam as alterações e quando os revisores votam. Se uma política disparar um build, o status de build será configurado como aguardando até que o build seja concluído.

Posso usar definições de build XAML em políticas de branch?

Não, você não pode usar definições de build XAML em políticas de branch.

Quais caracteres curinga posso usar para revisores de código necessários?

Os asteriscos únicos * correspondem a qualquer número de caracteres, incluindo barras / e barras inversa\. Os pontos de interrogação ? correspondem a qualquer caractere único.

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 repositório.
  • */.gitignore corresponde a qualquer arquivo .gitignore no repositório.

Os caminhos do revisor de código necessário diferenciam maiúsculas de minúsculas?

Não, as políticas de branch 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 grupoe, em seguida, adicionar o grupo como um revisor. Qualquer membro do grupo pode aprovar para atender ao requisito de política.

Tenho permissões de política de bypass. Por que ainda vejo falhas de política no status da solicitação de pull?

As políticas configuradas são sempre avaliadas para alterações de solicitação de pull. Para usuários que têm permissões de política de bypass, o status da política relatada é apenas consultoria. Se o usuário com permissões de bypass aprovar, o status da falha não bloqueará a conclusão da solicitação de pull.

Por que não consigo concluir minhas próprias solicitações de pull quando "Permitir que os solicitantes aprovem suas próprias alterações está definida"?

Tanto a política Exige um número mínimo de revisores e a política de 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 de pull tem as seguintes políticas definidas:

  • Exigir um número mínimo de revisores requer pelo menos um revisor.
  • Os revisores incluídos automaticamente exigem que você ou uma equipe em que você esteja como revisor.
  • Os revisores incluídos automaticamente têm Permitir que os solicitantes aprovem suas próprias alterações habilitado.
  • Exigir um número mínimo de revisores não Permite que os solicitantes aprovem suas próprias alterações habilitadas.

Nesse caso, sua aprovação atende aos revisores incluídos automaticamente, mas nãoRequer um número mínimo de revisores , deste modo, você não pode concluir a solicitação de pull.

Também pode haver outras políticas, como Proibir que o pusher mais recente aprove suas próprias alterações, que impedem que você aprove suas próprias alterações mesmo se permitir que os solicitantes aprovem suas próprias alterações esteja definida.

O que acontece quando o caminho nos filtros de caminho não começa com / nem com um curinga?

O caminho nos filtros de caminho que não começa com / nem com um curinga não terá efeito e o filtro de caminho será avaliado como se esse caminho não tivesse sido especificado. Essa caminho não pode corresponder ao / com que o caminho absoluto do arquivo começa.