Um espaço de trabalho de revisão de código deve ajudar você a conectar a intenção proposta, as linhas alteradas, as evidências de tempo de execução e a decisão final. Ele não deve exigir que todos os repositórios e painéis da organização permaneçam abertos.
Estabeleça o limite da revisão
Leia a descrição do pull request, a issue vinculada, o branch base e o comportamento afetado. O GitHub recomenda criar contexto antes de revisar Files changed (Arquivos alterados). Anote os arquivos de maior risco e a validação esperada, depois abra o repositório e o branch correspondentes no editor.
Coloque o diff ao lado do código local quando a navegação entre definições for necessária. Mantenha a saída de teste ou build em uma janela de terminal e abra a pré-visualização do produto somente quando a alteração tiver comportamento visível para o usuário. Marque os arquivos revisados apenas após verificar a versão atual; o GitHub limpa o estado de visualização quando um arquivo é alterado.
Separe as evidências da discussão
Use comentários de linha para descobertas específicas, sugestões para edições exatas e um resumo da revisão para conclusões transversais. Verifique as Checks (Verificações) automatizadas do pull request e inspecione as alterações de dependência quando relevante. Uma verificação verde não substitui a leitura do diff do código-fonte.
Conclua com uma decisão de revisão
Envie Comment (Comentário), Approve (Aprovar) ou Request changes (Solicitar alterações) com base na política de revisão do repositório e nas evidências observadas. Interrompa os processos locais e feche as janelas temporárias posteriormente. O Wallo pode agrupar o navegador de diff, o editor, o terminal e as janelas de pré-visualização, mas ele não conhece o estado do pull request ou a decisão de revisão.