Partilhar via

Acerca dos pedidos pull

  • Artigo

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

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 RPs podem vir de filiais dentro do mesmo repositório ou de filiais em bifurcações do repositório. As equipes usam RPs para revisar o código e dar feedback sobre as alterações antes de mesclar 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 solicitação pull e considerações de gerenciamento. 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 habilitados em 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 exibir ou revisar RPs, você deve ser membro de um projeto de DevOps do Azure com acesso Básico ou superior.

  • Para contribuir para uma RP, tem de ser membro do grupo de segurança Leitores ou ter as permissões correspondentes.

  • Para criar e concluir uma RP, você deve ser membro do grupo de segurança Colaboradores ou ter as permissões correspondentes.

Nota

Para projetos públicos, os usuários com acesso de Partes Interessadas têm acesso total aos Repositórios do Azure.

  • Os repositórios devem estar habilitados em 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 exibir ou revisar RPs, você deve ser membro de um projeto de DevOps do Azure com acesso Básico ou superior. Se você não for um membro do projeto, seja adicionado.
  • Para contribuir para uma RP, tem de ser membro do grupo de segurança Leitores ou ter as permissões correspondentes.
  • Para criar e concluir uma RP, você deve ser membro do grupo de segurança Colaboradores ou ter 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 RP devem:

  • Certifique-se de selecionar os revisores certos para atribuir a um RP.
  • 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 solicitações pull do Git.

Políticas de filiais e solicitações pull

Sua equipe pode contar com ramificações críticas em seu repositório, como a main filial, para estar sempre em boa forma. Você pode definir políticas de ramificação para exigir RPs 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 RPs para impor uma melhor qualidade de código nas principais ramificações. 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 RPs antes que os PRs possam se fundir. É 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

Requer aprovação de um número especificado de revisores em solicitações pull.

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 em solicitações pull.

Limitar tipos de mesclagem

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 pré-mesclando e criando alterações de solicitação pull. Também pode ativar ou desativar políticas.

Adicionar políticas de verificação de status

Inativo

Adicione uma ou mais políticas para exigir que outros serviços publiquem o status bem-sucedido para concluir solicitações pull. 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 cobrir essas necessidades, você pode integrar verificações de status de RP no fluxo de trabalho de RP. Com as verificações de status de RP, os serviços externos podem assinar programaticamente as alterações de código, associando informações de sucesso ou falha ao PR.

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

Problema de base de várias intercalações

Em alguns casos, um PR tem mais de uma base de mesclagem verdadeira, e essa situação pode causar problemas de segurança. Se os ficheiros no pedido Pull tiverem versões diferentes entre as bases de intercalação, ocorrerá um aviso de bases de intercalação múltiplas. Para obter mais informações e correção, consulte Várias bases de mesclagem.

Próximos passos