Partilhar via

Acerca dos pedidos de pull

Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022

As solicitações pull (PRs) são uma maneira de alterar, revisar e mesclar código em um repositório Git no Azure Repos. As PRs podem vir de ramos dentro do mesmo repositório ou de ramos em forks do repositório. As equipas utilizam PRs para revisar o código e fornecer feedback sobre as alterações antes de incorporar o código na ramificação principal. Os revisores podem percorrer as alterações propostas, deixar comentários e votar para aprovar ou rejeitar o código.

Este artigo descreve as diretrizes de pull request e considerações de gestão. Para obter instruções sobre como criar, exibir, revisar e concluir solicitações pull, consulte os seguintes artigos:

Nota

Por motivos de desempenho e estabilidade, o número de revisores que podem ser adicionados a uma solicitação pull deve ser 1000 ou menos. Novas solicitações pull não serão criadas ao adicionar mais de 1000 revisores, e as solicitações pull existentes não permitirão que você adicione mais de 1000 revisores.

Permissões e pré-requisitos

  • Os repositórios devem estar ativados no seu projeto. Se o hub Repos e as páginas associadas não forem exibidos, consulte Ativar ou desativar um serviço de DevOps do Azure para reativar Repos.

  • Para visualizar ou rever RPs, seja membro de um projeto do Azure DevOps com pelo menos acesso Básico .

  • Para contribuir para um PR, seja membro do grupo de segurança Leitores ou tenha as permissões correspondentes.

  • Para criar e concluir uma PR, seja membro do grupo de segurança Colaboradores ou possua as permissões correspondentes.

Nota

Para projetos públicos, os utilizadores com acesso de Parte Interessada têm acesso total aos Repositórios do Azure.

  • Os repositórios devem estar ativados no seu projeto. Se o hub Repos e as páginas associadas não forem exibidos, consulte Ativar ou desativar um serviço de DevOps do Azure para reativar Repos.
  • Para visualizar ou rever RPs, seja membro de um projeto do Azure DevOps com pelo menos acesso Básico . Se você não for um membro do projeto, seja adicionado.
  • Para contribuir para um PR, seja membro do grupo de segurança Leitores ou tenha as permissões correspondentes.
  • Para criar e concluir uma PR, seja membro do grupo de segurança Colaboradores ou possua as permissões correspondentes.

Para obter mais informações sobre permissões e acesso, consulte Permissões padrão de repositório Git e ramificações e Sobre níveis de acesso.

Feedback de qualidade para solicitações pull

As avaliações de alta qualidade começam com feedback de alta qualidade. Aqui estão algumas chaves para um ótimo feedback de RP:

  • O proprietário de RP deve ter as pessoas certas para revisar o PR e certificar-se de que os revisores sabem o que o código faz.
  • Os revisores devem dar feedback prático e construtivo.
  • Os proprietários e revisores devem comentar e responder rapidamente.

Os proprietários de Relações Públicas devem:

  • Certifique-se de selecionar os revisores certos para atribuir a um PR.
  • Inclua revisores que saibam como o código funciona.
  • Peça aos programadores que trabalham noutras áreas que partilhem as suas ideias.
  • Forneça uma descrição clara das alterações.
  • Forneça orientação ao revisor com modelos de solicitação pull.
  • Forneça uma compilação do código com a correção ou recurso em execução nele.
  • Responda aos comentários, aceitando a sugestão ou explicando por que a alteração sugerida não é a ideal.
  • Para boas sugestões fora do escopo do PR, crie novos itens de trabalho, ramificações e RPs para fazer essas alterações.

Os revisores devem realizar as seguintes tarefas.

  • Fornecer feedback sobre alterações com as quais não concordam
  • Identificar problemas e dar sugestões específicas sobre o que fazer diferente
  • Certifique-se de que o feedback tem uma intenção clara e é fácil de entender
  • Deixe comentários ou vote nas alterações

Para obter mais informações, consulte Obter feedback com pull requests do Git.

Políticas de ramificações e pull requests

A sua equipa pode contar com ramos críticos no seu repositório, como o ramo main, para que esteja sempre em bom estado. Você pode definir políticas de branches para exigir PRs para quaisquer alterações nessas ramificações protegidas e rejeitar quaisquer alterações enviadas diretamente para as ramificações.

Você pode adicionar mais políticas aos PRs para impor uma melhor qualidade de código nas ramificações principais. Requisitos extras, como uma compilação limpa do código proposto ou a aprovação de vários revisores, podem ajudar a proteger ramificações importantes.

Você pode definir o número de aprovações necessárias para uma RP em uma política de filial. Você também pode definir determinados revisores como obrigatórios ou opcionais em todos ou alguns RPs. Um PR pode ser configurado para preenchimento automático com o número necessário de aprovações, mesmo que outros revisores rejeitem as alterações. No entanto, os revisores necessários devem aprovar os PRs antes que possam ser fundidos. É uma prática recomendada que pelo menos dois revisores analisem e aprovem alterações em um RP significativo.

Para redefinir votos sempre que um autor de RP enviar novas alterações, selecione Redefinir votos do revisor de código quando houver novas alterações na política de ramificação Exigir um número mínimo de revisores .

A tabela a seguir resume as políticas que você pode definir para personalizar uma ramificação. 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.

Política

Predefinição

Descrição

Exigir um número mínimo de revisores

Inativo

Exigir aprovação de um número especificado de revisores em pull requests.

Verificar itens de trabalho vinculados

Inativo

Incentive a rastreabilidade verificando itens de trabalho vinculados em solicitações pull

Verificar a resolução de comentários

Inativo

Verifique se todos os comentários foram resolvidos nos pull requests.

Limitar tipos de fusão

Inativo

Controle o histórico de ramificações limitando os tipos disponíveis de mesclagem quando as solicitações pull forem concluídas.

Adicionar políticas de validação de compilação

Inativo

Adicione uma ou mais políticas para validar o código antes de mesclar e compilar as alterações na solicitação de pull. Também pode ativar ou desativar políticas.

Adicionar políticas de verificação de status

Inativo

Adicione uma ou mais políticas de configuração para exigir que outros serviços reportem o estado de sucesso para concluir pull requests. Também pode ativar ou desativar políticas.

Revisores incluídos automaticamente

Inativo

Adicione uma ou mais políticas para designar revisores de código para incluir automaticamente quando solicitações pull alterarem determinadas áreas de código. Também pode ativar ou desativar políticas.

Para obter mais informações, consulte:

Definir verificações de status para melhorar a qualidade do código

As solicitações pull e as políticas de ramificação permitem que as equipes apliquem as práticas recomendadas para revisar o código e executar compilações automatizadas. Muitas equipes têm outros requisitos e validações para fazer no código. Para satisfazer estas necessidades, pode integrar verificações de status de PR no fluxo de trabalho de PR. Com as verificações de estado de PR, os serviços externos podem aprovar programaticamente as alterações de código, associando informações de sucesso ou insucesso ao PR.

Para obter mais informações, consulte os seguintes artigos:

Problema de base de múltiplas fusões

Em alguns casos, um PR tem mais de uma base de junção verdadeira, e essa situação pode causar problemas de segurança. Se os ficheiros no pull request tiverem versões diferentes entre os pontos de fusão, ocorrerá um aviso de múltiplos pontos de fusão. Para obter mais informações e correção, consulte Várias bases de fusão.

Próximos passos

  • Last updated on