Colaborar com solicitações de pull
As solicitações de pull permitem que você informe outras pessoas sobre as alterações que você enviou por push a um repositório do GitHub.
Depois que uma solicitação de pull é enviada, as partes interessadas podem examinar o conjunto de alterações, discutir as possíveis modificações e até mesmo efetuar push de commits de acompanhamento, se necessário.
As solicitações de pull geralmente são usadas por equipes e organizações que colaboram usando o Modelo de Repositório Compartilhado.
Todos compartilham apenas um repositório e os branches de tópico são usados para desenvolver recursos e isolar alterações.
Muitos projetos de código aberto no GitHub usam solicitações de pull para gerenciar alterações de colaboradores.
Elas ajudam a oferecer uma forma de notificar os mantenedores de projeto sobre as alterações feitas.
Além disso, iniciam a revisão de código e a discussão geral sobre um conjunto de alterações antes de mesclar ao branch principal.
As solicitações de pull combinam a revisão e a mesclagem do código em um único processo de colaboração.
Quando terminar de corrigir um bug ou um novo recurso em um branch, crie uma solicitação de pull.
Adicione os membros da equipe à solicitação de pull para que eles possam examinar suas alterações e votar nelas.
Use solicitações de pull para examinar os trabalhos em andamento e obter comentários antecipados em relação às alterações.
Não há compromisso de mesclar as alterações, uma vez que o proprietário pode abandonar a solicitação de pull a qualquer momento.
Obtenha a revisão do seu código
A revisão de código feita em uma solicitação de pull não serve apenas para encontrar bugs; essa é a tarefa dos testes.
Uma boa revisão de código encontra problemas menos óbvios que podem ocasionar problemas caros posteriormente.
As revisões de código ajudam a proteger sua equipe contra mesclagens ruins e builds corrompidos que minam a produtividade da sua equipe.
A revisão encontra esses problemas antes da mesclagem, protegendo seus branches essenciais contra alterações indesejadas.
Dissemine a experiência e distribua estratégias de solução de problemas usando uma ampla variedade de revisores em suas revisões de código.
A difusão de habilidades e conhecimento torna sua equipe mais robusta e resiliente.
Fornecer ótimos comentários
As revisões de alta qualidade começam com comentários de alta qualidade. Os fundamentos dos comentários excelentes em uma solicitação de pull são:
- Fazer com que as pessoas certas revisem a solicitação de pull.
- Certificar-se de que os revisores saibam o que o código faz.
- Fornecer comentários úteis e construtivos.
- Responder aos comentários imediatamente.
Ao atribuir revisores à sua solicitação de pull, selecione o conjunto certo de revisores.
Você quer revisores que saibam como seu código funciona e tenta incluir desenvolvedores que trabalham em outras áreas para compartilhar as ideias.
Além disso, quem possa fornecer uma descrição clara das alterações e criar o código que tenha a correção ou recurso em execução nele.
Os revisores devem tentar fornecer comentários sobre as alterações com as quais eles não concordam. Identificar o problema e dar uma sugestão específica sobre o que fariam de maneira diferente.
O comentário deve ter uma intenção clara e ser fácil para o proprietário da solicitação de pull entender.
O proprietário da solicitação de pull deve responder aos comentários, aceitar a sugestão ou explicar por que a alteração sugerida não é a ideal.
Às vezes, uma sugestão é boa, mas as alterações estão fora do escopo da solicitação de pull.
Pegue essas sugestões e crie novos itens de trabalho e branches de recursos separados da solicitação de pull para fazer essas alterações.
Proteger branches com políticas
Seus repositórios normalmente contêm um ou mais branches, incluindo o main, que exigem proteção extra devido à sua criticidade. O Azure Repos oferece vários mecanismos baseados em políticas que você deve considerar implementar para ajudá-lo a atingir essa meta.
A premissa básica desses mecanismos é aplicar restrições a pull requests. Por exemplo, você pode incluir a imposição de políticas de revisão de código específicas, como exigir um número mínimo de aprovações de revisores designados antes que um pull request possa ser mesclado. Usar a experiência coletiva certamente vai melhorar a qualidade e confiabilidade das mudanças de código.
Além disso, considere implementar a política de Verificação de itens de trabalho vinculados. Isso verifica se cada pull request está vinculado a um item de trabalho, fornecendo contexto e promovendo a rastreabilidade. A política de Verificação de resolução de comentários ajuda a garantir que todos os comentários de revisão de código sejam tratados antes de mesclar o pull request.
As políticas relacionadas às verificações automatizadas de análise de código, teste e conformidade confirmam que as alterações atendem aos padrões predefinidos antes da integração. Limitar os tipos de mesclagem ajuda a manter o controle do histórico do branch. Por exemplo, você tem a opção de permitir apenas mesclagens rápidas e squash.
Também é possível exigir compilações limpas das novas versões de código antes de permitir que sejam mescladas nos branches críticos. Isso garantirá que as alterações mescladas não introduzam falhas de compilação ou problemas de regressão. As verificações de status podem ser usadas para condicionar a conclusão dos pull requests a sinais gerados por serviços externos. Por exemplo, esses sinais podem ser gerados pelo Azure Pipelines executando testes automatizados e análise de código.
Quaisquer branches que tenham políticas necessárias configuradas automaticamente bloqueiam o push direto, efetivamente exigindo pull requests para todas as alterações. Além disso, esses branches não podem ser excluídos.