Passo 1 de 7
Reconhecer os papéis na revisão
Identifique as responsabilidades de autor e revisor e reconheça o ciclo de colaboração em um pull request aberto.
Trilha de aprendizado · Nível 4 · Tutorial 2
Você será capaz de participar de uma rodada de revisão, registrar comentários úteis e responder ao feedback com novos commits que atualizam o mesmo pull request.
Reconhecer os papéis na revisão
Identifique as responsabilidades de autor e revisor e reconheça o ciclo de colaboração em um pull request aberto. 2 min
Comentar um trecho com clareza
Localize a linha relevante e prepare um comentário com uma observação concreta, contexto e uma sugestão ou pergunta objetiva. 3 min
Escolher o resultado e enviar a revisão
Reúna comentários em uma revisão, escolha um parecer coerente e confira a publicação no pull request de outra pessoa. 3 min
Responder ao feedback com uma ação clara
Responda às conversas de revisão indicando um ajuste planejado ou pedindo esclarecimento, sem tratar uma intenção como trabalho concluído. 2 min
Publicar ajustes no mesmo pull request
Registre os ajustes na branch de origem e publique os novos commits para atualizar a proposta existente. 4 min
Conferir os ajustes e acompanhar as conversas
Compare o feedback com as alterações publicadas e decida quais conversas podem ser resolvidas e quais precisam continuar abertas. 3 min
Aplicar o ciclo completo de revisão
Simule uma rodada de revisão de documentação, alternando entre revisor e autor até conferir os ajustes e as conversas pendentes. 3 min
Passo 1 de 7
Identifique as responsabilidades de autor e revisor e reconheça o ciclo de colaboração em um pull request aberto.
Agora, a proposta entra em uma rodada de colaboração.
Autor: é responsável pela proposta, por responder ao feedback e por fazer os ajustes necessários.
Revisor: examina a mudança e comunica observações fundamentadas no que encontrou.
Dica
Autor e revisor devem manter a conversa centrada na proposta. Identificar um problema no conteúdo não é julgar a capacidade de quem o escreveu.
Relacione cada ação ao papel responsável. Uma delas é responsabilidade dos dois.
Toque em um item e depois no par correspondente.
Uma rodada pode seguir este caminho: revisão → resposta do autor → ajustes → nova conferência.
Exemplo
Ana é autora de uma atualização no guia de instalação. Bruno é o revisor.
O problema está no conteúdo do guia, não na pessoa que o escreveu.
Passo 2 de 7
Localize a linha relevante e prepare um comentário com uma observação concreta, contexto e uma sugestão ou pergunta objetiva.
Na aba de arquivos alterados do pull request, abra o arquivo relevante e leia o trecho junto com as linhas próximas.
No computador, passe o ponteiro ao lado do número da linha e clique no botão + que aparece para abrir o campo de comentário. Se a observação for sobre um texto adicionado, escolha a linha na nova versão.
Dica
Escolha a linha que contém o ponto observado. Assim, o autor consegue identificar exatamente a qual parte da mudança seu comentário se refere.
Neste projeto fictício, o botão na tela se chama Exportar PDF. O pull request adiciona estas linhas ao arquivo README.md:
12 — Exportar relatório
13 — Clique no botão “Baixar PDF”.
14 — Escolha a pasta para salvar o arquivo.
Em qual linha você deve comentar a diferença entre o nome documentado e o nome exibido na tela?
Um comentário útil responde a três perguntas:
Exemplo
“A instrução usa ‘Baixar PDF’, mas o botão na tela se chama ‘Exportar PDF’. Essa diferença pode dificultar a localização do botão. Podemos usar aqui o mesmo nome exibido na tela?”
Dica
Evite “Está confuso” (vago), “Troque isso” (sem justificativa) e “Você não conferiu” (julgamento pessoal). Aponte o conteúdo e explique o motivo.
Na tela de cadastro há dois botões: Salvar rascunho e Concluir cadastro. Só o segundo finaliza o cadastro.
O pull request adiciona este trecho a guia.md:
20 — Finalizar o cadastro
21 — Preencha os campos obrigatórios.
22 — Clique no botão.
Indique a linha pertinente e escreva um comentário respeitoso com uma observação verificável, o motivo da preocupação e uma sugestão ou pergunta objetiva.
Escreva pelo menos 40 caracteres (0/40).
Passo 3 de 7
Reúna comentários em uma revisão, escolha um parecer coerente e confira a publicação no pull request de outra pessoa.
No pull request de outra pessoa, retome o comentário que você redigiu no trecho alterado. Clique em Iniciar uma revisão (Start a review) para registrá-lo como pendente. Só digitar no campo não basta.
Para acrescentar outras observações, abra o campo na linha correspondente, escreva e clique em Adicionar comentário à revisão (Add review comment). Esses comentários ficam pendentes até você enviar a revisão.
Dica
Adicionar comentário avulso (Add single comment) publica a observação imediatamente, sem reuni-la em uma revisão pendente. Aqui, vamos reunir os comentários e enviá-los com um parecer.
Atenção
O autor não pode aprovar o próprio pull request. Para praticar a aprovação, revise uma proposta de outra pessoa.
Ligue cada situação ao resultado ou à regra aplicável.
Toque em um item e depois no par correspondente.
Na aba Arquivos alterados (Files changed), clique em Revisar alterações (Review changes) para abrir o painel.
Confira os comentários reunidos, escreva um resumo do parecer e escolha Comentário, Aprovação ou Solicitação de alterações. Se pedir ajustes, deixe claro o que precisa mudar e por quê.
Clique em Enviar revisão (Submit review). Abrir o painel ou selecionar o resultado ainda não publica a revisão.
Depois, volte à aba Conversa (Conversation) do pull request e confira se o parecer e os comentários foram publicados.
Você revisa uma proposta de outra pessoa. O primeiro comentário está apenas digitado, e você quer reunir duas observações sobre ajustes necessários. Ordene as ações.
Passo 4 de 7
Responda às conversas de revisão indicando um ajuste planejado ou pedindo esclarecimento, sem tratar uma intenção como trabalho concluído.
Agora você está no papel de autor. Leia o parecer enviado, o comentário e o trecho ao qual ele se refere. Use o campo de resposta da conversa correspondente para manter pedido e resposta juntos.
Se o pedido está claro e faz sentido para a proposta, reconheça o ponto e diga qual ajuste pretende fazer.
Exemplo
Revisor: “O link do guia está quebrado. Pode trocar pelo endereço atual?”
Autor: “O link ainda aponta para a página antiga. Vou substituir pelo endereço atual do guia.”
Dica
“Vou ajustar” comunica um plano. Só afirme que o ajuste foi publicado e conferido quando isso realmente tiver acontecido.
No README.md, o revisor comentou: “A instrução não informa onde executar o comando. Pode indicar que é na pasta do projeto?”
Você concorda, mas ainda não editou o arquivo. Escreva uma resposta para essa conversa.
Escreva pelo menos 20 caracteres (0/20).
Se não entendeu o pedido, diga o que precisa esclarecer e faça uma pergunta específica antes de prometer um ajuste.
Se discordar, explique o motivo relacionado à proposta e sugira uma alternativa ou pergunte sobre a preocupação do revisor. Responder ao feedback não significa aceitar toda sugestão.
Exemplo
Revisor: “Podemos remover o exemplo para encurtar o guia?”
Autor: “Entendo a preocupação com o tamanho. Incluí o exemplo para ajudar quem está começando. Podemos encurtar a explicação e manter o exemplo?”
O revisor comentou na seção de instalação: “Pode simplificar esta parte?”
Você não sabe se ele quer menos etapas ou explicações mais curtas. Ainda não fez ajustes. Escreva uma resposta que ajude a esclarecer o pedido.
Escreva pelo menos 20 caracteres (0/20).
Passo 5 de 7
Registre os ajustes na branch de origem e publique os novos commits para atualizar a proposta existente.
Como autor, você já definiu o ajuste. Agora, confira a branch de origem do pull request e o remoto que aponta para o repositório onde ela está publicada. No computador, verifique o estado local e a branch atual. Se houver alterações pendentes, organize esse trabalho antes de trocar de branch.
Exemplo
Seu PR tem origem em melhorar-instrucoes e destino em main, no repositório associado a origin. O feedback pede incluir o comando de instalação no README.md.
Faça o ajuste e registre o commit em melhorar-instrucoes, não em main nem em uma nova branch.
Dica
Confira as diferenças, prepare apenas os ajustes e crie o commit. Depois, publique no mesmo remoto e na mesma branch de origem. Quando o push é concluído, o PR aberto é atualizado automaticamente. Um commit apenas local ainda não aparece nele — e não é preciso abrir outro PR.
O pedido foi compreendido e o estado local está limpo. Ordene as ações para atualizar o pull request existente.
Neste exemplo, a branch local melhorar-instrucoes já existe. Confira se origin aponta para o repositório da proposta. Execute a troca de branch somente após confirmar que não há alterações locais pendentes.
git status
git remote -v
# Continue somente com o estado local limpo.
git switch melhorar-instrucoes
git statusCom melhorar-instrucoes selecionada, edite o README.md para incluir o comando solicitado. Depois, execute o fluxo abaixo, conferindo as diferenças antes de avançar. Os nomes usados são deste exemplo; no seu projeto, use o arquivo, o remoto e a branch de origem reais.
git diff
git add README.md
git diff --staged
git commit -m "Documenta o comando de instalação"
git push origin melhorar-instrucoesVocê criou o commit de ajuste em melhorar-instrucoes, mas ainda não o publicou. No GitHub, o PR dessa branch para main continua sem o ajuste. O remoto da proposta é origin. Qual ação falta?
Passo 6 de 7
Compare o feedback com as alterações publicadas e decida quais conversas podem ser resolvidas e quais precisam continuar abertas.
No mesmo pull request, abra a lista de commits e confira se os ajustes publicados aparecem. Depois, vá à área de arquivos alterados e examine as diferenças atualizadas.
Para cada conversa, compare o pedido com o trecho atual: o ajuste atende a tudo o que foi solicitado? Falta alguma parte? Há uma dúvida ou discordância ainda em discussão?
Dica
Um commit chamado “Ajustes da revisão” não garante que todos os pedidos foram atendidos. A evidência está no conteúdo efetivamente publicado.
Relacione cada pedido e seu resultado à situação correspondente.
Toque em um item e depois no par correspondente.
Depois de conferir, responda na conversa indicando o ajuste realizado e onde encontrá-lo.
Se o pedido foi atendido e não há discussão pendente, use a ação de resolver a conversa, quando disponível. Se falta algo ou ainda há dúvida ou discordância, mantenha-a aberta e indique a pendência.
Resolver uma conversa não significa aprovar o pull request inteiro.
Exemplo
“Incluí a versão necessária e o comando de instalação no README.md, na seção ‘Instalação’. Conferi os dois nas diferenças atualizadas deste pull request.”
Dica
Uma conversa pode aparecer associada a um trecho desatualizado porque o código ou texto mudou. Esse aviso não comprova a correção: compare o pedido com a versão atual.
Você está revisando o pull request de outra pessoa. Pediu exemplos para dois formatos de data. Após um novo commit, a conversa aparece como desatualizada, mas o arquivo atual contém exemplo de apenas um formato. O que fazer?
Passo 7 de 7
Simule uma rodada de revisão de documentação, alternando entre revisor e autor até conferir os ajustes e as conversas pendentes.
Você é revisor de um pull request de Joana. A branch de origem é docs/instrucoes, publicada em origin.
O PR adiciona esta linha ao README:
“Leia o guia em docs/manual.md.”
Você conferiu o repositório: o guia está em docs/guia.md; docs/manual.md não existe.
Escreva o comentário que você anexaria a essa linha nos arquivos alterados. Inclua a observação, seu impacto e uma sugestão ou pergunta objetiva.
Escreva pelo menos 30 caracteres (0/30).
Seu comentário está pendente na revisão. Você considera a correção necessária para que a instrução funcione. Como concluir?
Agora você representa Joana. A revisão foi publicada. Além do caminho incorreto, outra conversa pergunta: “O guia também funciona no Linux?”. Isso ainda precisa ser confirmado.
Como autora, você responde e ajusta a proposta; não pode aprovar o próprio PR.
Ordene o encaminhamento, começando pelas respostas nas conversas correspondentes.
No mesmo PR, você conferiu o novo commit e as diferenças: o README agora aponta para docs/guia.md, que existe. Joana respondeu na conversa indicando o ajuste e onde conferi-lo.
A pergunta sobre qual distribuição Linux validar continua sem resposta, e o funcionamento nesse sistema não foi confirmado.
Com base no que você conferiu, como acompanhar os dois pontos?
Resumo
Parabéns! Você concluiu: Revisar e atualizar um pull request
Você concluiu “Revisar e atualizar um pull request”. A integração da proposta será tratada no próximo tutorial.
Milhares de cursos online em vídeo, ebooks e áudiobooks.
Para testar seus conhecimentos no decorrer dos cursos online
Gerado diretamente na galeria de fotos do seu celular e enviado ao seu e-mail
Baixe nosso aplicativo pelo QR Code ou pelos links abaixo:.
Leve o conhecimento no seu bolso.
Baixe o aplicativo Cursa.
São centenas de Cursos gratuitos a disposição, com Certificado de conclusão gratuito que é salvo em sua galeria de imagens do celular.
Baixe o app para ter acesso ao Certificado de conclusão de Curso Gratuitamente.
+ de 10 milhões
de alunos
Certificado grátis e
válido em todo o Brasil
60 mil exercícios
gratuitos
4,8/5 classificação
nas lojas de apps
Cursos gratuitos em
vídeo, ebooks e audiobooks
