Estamos mudando do Bitbucket para o GitHub e uma coisa com a qual estamos lutando são as revisões de código por pares que funcionaram muito bem no Bitbucket assim:
- O autor abriu uma solicitação de recebimento (GitHub: o mesmo)
- O autor adicionou seus colegas como revisores (GitHub: ?? lutando aqui com vários responsáveis)
- Revisor:
- Aprovou o PR com uma marca de seleção verde (GitHub: ??)
- Comentários adicionados (GitHub: o mesmo)
- Criou tarefas leves (GitHub: semelhante à
- [ ]sintaxe usada na descrição de relações públicas; pena que não funcione para tarefas)
- Há uma lista de PRs onde eu posso ver rapidamente que são revisadas e OK para serem mescladas e que precisam de mais atenção (GitHub: ??)
Devo salientar que queremos evitar ferramentas de revisão de código de terceiros, se possível, e gostaríamos de permanecer no GitHub de baunilha com algum tipo de solução alternativa.
code-reviews
github
pull-requests
Borek Bernard
fonte
fonte
Respostas:
Pelo que vi, a maioria dessas etapas é executada no Github por convenção e não por qualquer processo oficial fornecido pelo Github.
Meu empregador usa o Github, administro um bom número de pequenos projetos de código aberto e faço contribuições ocasionais para outros projetos de código aberto.
Aqui está como eu normalmente vi isso sendo feito:
Autor que adiciona seus colegas como revisores:
Isso varia de projeto para projeto, mas, em geral, os revisores atribuídos são todos os colaboradores do projeto .
Os projetos de código aberto parecem ter uma hierarquia aproximada - talvez a convenção deles seja apenas mesclar depois que um colaborador "básico" concordar.
Na loja em que estou atualmente empregado, nos fundimos depois que qualquer uma das meia dúzia de desenvolvedores da equipe aprovou.
Em raras ocasiões, alguém da equipe pode usar um comentário para chamar especificamente outro desenvolvedor que eles acham que deve revisar o código antes da fusão, mas, caso contrário, quem chegar lá primeiro e sentir vontade de fazê-lo pode revisar e fazer comentários.
Aprovação do revisor:
Normalmente, a aprovação é mostrada ao comentar a solicitação de recebimento dizendo "+1" ou "lgtm" (me parece bom).
Tarefas leves:
Também usei as caixas de seleção, mas na maioria dos casos, todos os comentários em uma solicitação pull são considerados uma "tarefa" implícita que é resolvida por:
Vendo de relance o que é aprovado e o que ainda precisa ser revisto:
Eu usei a extensão Looks Good To Me para o Chrome, que oferece uma visão desse tipo na tela Pull Requests. A exibição da lista de solicitações de recebimento parece ter sido interrompida por alterações recentes no Github.
fonte