Como revisar o código dos outros no GitHub

Revisar é uma forma de contribuir que não exige permissão especial. Veja o caminho no GitHub e como comentar bem.

Como revisar um pull request no GitHub?

Abra a aba Files changed, comente nas linhas, clique em Start a review e, ao terminar, escolha Comment, Approve ou Request changes. Leia a descrição antes, teste a mudança e comente o código, não a pessoa.

Revisar também é contribuir

A Open Source Guides lista a revisão do trabalho de outras pessoas entre as formas de contribuir, ao lado de código, documentação e suporte. É também um bom jeito de aprender um projeto: você lê o código com um objetivo e vê como quem mantém discute o que aceita. Você não precisa de permissão especial para comentar em pull requests de um repositório público.

Como funciona a revisão no GitHub

A documentação do GitHub descreve o caminho assim:

Abra o pull request e clique na aba Files changed.
Passe o mouse sobre uma linha e clique no ícone azul de comentário. Para comentar várias linhas, selecione o intervalo arrastando ou com Shift nos números das linhas.
Escreva o comentário. Se quiser propor uma troca exata, use o ícone de sugestão e edite o texto dentro do bloco de sugestão.
Clique em Start a review. Os comentários ficam pendentes, visíveis só para você, até você enviar a revisão. Você pode editá-los ou descartar tudo em Submit review, depois Discard review.
Clique em Review changes, escreva um resumo e escolha uma das três opções: Comment, Approve ou Request changes. Termine com Submit review.

Comment é um retorno geral, sem aprovar nem bloquear. Approve diz que está bom. Request changes pede ajustes antes do merge.

Um roteiro de leitura

Estas dicas são prática comum, não regra oficial:

Leia primeiro a descrição e a issue ligada. Entenda o objetivo antes de olhar o código.
Rode a mudança quando der: baixe a branch do autor e teste. Muitos erros só aparecem rodando.
Comece pelo que importa: comportamento e testes vêm antes de estilo.
Separe o que bloqueia do que é gosto. Marque comentários de gosto com "opcional" ou "nit", para o autor saber o que precisa mudar.
Pergunte antes de afirmar. "O que acontece se a lista vier vazia?" abre conversa; "isto está errado" fecha.
Elogie o que ficou bom. Quem manda o primeiro pull request lê cada palavra.

Tom

A Open Source Guides dá o princípio: seja claro, respeite as decisões da comunidade e tenha paciência. Comente o código, não a pessoa. Se você discorda de uma decisão de projeto, diga uma vez, com motivos, e aceite que quem mantém decide.

Exemplo resolvido: três comentários reescritos

Comentário seco	Comentário que ajuda
"Isso está errado."	"Se `lista` vier vazia, a linha 12 falha com índice fora do intervalo. Dá para conferir o tamanho antes?"
"Use outro nome."	"Opcional: `contarTarefas` diria mais que `f`. Sem pressa nisso."
"Falta teste."	"Pode incluir um teste para o caso do arquivo vazio, que é o que a issue relata?"

Os três dizem a mesma coisa que os comentários secos, mas apontam o lugar, o motivo e o que fazer. Na aba Files changed, o terceiro poderia ser enviado como Request changes e os dois primeiros como comentários da mesma revisão.

Quem está do outro lado pode ler como abrir um pull request de um fork.

Perguntas frequentes

Preciso ser mantenedor para revisar um pull request?

Para comentar em um pull request de um repositório público, não. A Open Source Guides lista a revisão do trabalho de outras pessoas entre as formas de contribuir. Aprovar ou pedir mudanças formalmente depende das permissões que o projeto der.

Qual a diferença entre Comment, Approve e Request changes?

Comment é um retorno geral, sem aprovar nem bloquear. Approve diz que a mudança está boa. Request changes pede ajustes antes do merge. As três opções aparecem em Review changes, depois de Start a review, segundo a documentação do GitHub.

O que é um comentário pendente?

Ao iniciar uma revisão com Start a review, seus comentários ficam visíveis só para você até enviar. Você pode editá-los ou descartar tudo em Submit review, Discard review. Só no envio o autor os vê e é notificado.

Como propor uma troca exata de texto?

No comentário, clique no ícone de sugestão e edite o texto dentro do bloco. O autor poderá ver exatamente o que você propõe. A documentação do GitHub descreve isso no passo de escrever o comentário.

Fontes deste guia

Abertas em 11/10/2026. O texto é nosso, em português; as fontes ficam aqui com link, licença e o que foi lido.

Reviewing proposed changes in a pull request (GitHub Docs)
A página não mostra data · aberta em 11/10/2026 · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
O que lemos: A aba Files changed, comentário em linha ou em várias linhas, sugestão de alteração, Start a review (comentários pendentes) e as três formas de enviar a revisão: Comment, Approve e Request changes.
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso.
How to Contribute to Open Source (Open Source Guides)
A página não mostra data · aberta em 11/10/2026 · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0
O que lemos: Contribuir vai além de código; arquivos-chave (LICENSE, README, CONTRIBUTING, CODE_OF_CONDUCT); conferir licença, commits recentes e tom do projeto; quando abrir issue e quando abrir pull request; comunicação pública e objetiva; o que fazer depois de enviar (esperar cerca de uma semana antes de cobrar, responder a pedidos de mudança, pedir retorno se recusado).
Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso.

Informação geral, não é aconselhamento jurídico. Quando um guia cita uma licença de conteúdo, ela vale para a página citada, não para este site.

Continue pelos guias

Os geradores, o passo a passo e os guias ficam a um clique.