diff antes de abrir PR: o hábito que reduz comentários de revisão

Você acabou de abrir o PR. Dois minutos depois, o primeiro comentário chega: "console.log esquecido na linha 47." Você sabe que poderia ter pegado isso se tivesse lido o diff antes de clicar em "Create pull request".

Esse ciclo — abre PR, recebe comentário óbvio, corrige, força o revisor a olhar de novo — é mais caro do que parece. Esse post é sobre o hábito que interrompe ele.

O que muda quando você lê o próprio diff

Quando você escreve código, você está no contexto. Você sabe por que cada linha está ali, o que estava pensando, o que testou. Quando você abre o diff — especialmente numa interface visual com cores — você muda de perspectiva. Você passa a ver o que vai ser revisado, não o que foi escrito.

Essa mudança de perspectiva é real e pequenas coisas ficam imediatamente visíveis: o console.log de debug, a variável que foi renomeada em três de quatro lugares, o comentário que ficou desatualizado depois da refatoração, o arquivo de configuração que não deveria estar no PR.

Não é que você estava sendo descuidado. É que no contexto de escrever, você não estava olhando para o resultado — estava olhando para o processo. O diff força a visão do resultado.

O custo real de pular essa etapa

Um comentário óbvio num PR não é só uma correção de dois minutos. É:

• O revisor precisou abrir o PR, ler o contexto, identificar o problema e escrever o comentário
• Você precisa voltar ao contexto do que estava fazendo, corrigir, commitar, re-pedir review
• O revisor precisa olhar de novo — mesmo que só para marcar o comentário como resolvido

Em times com review síncrono, cada ciclo extra pode custar horas de espera. Em times assíncronos, pode custar um dia inteiro de atraso.

A matemática é simples: cinco minutos de self-review antes de abrir o PR podem eliminar um ciclo inteiro de revisão.

git diff na linha de comando vs interface visual

Para self-review, a interface visual ganha. O git diff no terminal é útil para inspecionar arquivos específicos ou comparar branches, mas para uma revisão completa do que você está prestes a submeter, uma visualização lado a lado com highlight de adições e remoções é mais eficiente.

# Ver o que está staged (o que vai pro commit)
git diff --staged

# Ver tudo que mudou em relação à main
git diff main...HEAD

O problema do terminal é que o output é linear — você rola por um arquivo longo sem a âncora visual de "isso foi adicionado" vs "isso foi removido". Para diffs grandes, a tendência é perder atenção no meio.

A interface visual resolve isso. Você vê o before e o after lado a lado, e o olho humano é bom em identificar diferenças quando tem as duas versões em paralelo.

O que olhar no diff (checklist prático)

Não é uma revisão técnica profunda — isso é trabalho do reviewer. É uma limpeza antes de entregar.

O que você está procurando:

• Debug esquecido: console.log, print, var_dump, dd(), breakpoints
• Arquivos que não deveriam estar no PR: .env, arquivos de configuração local, arquivos gerados automaticamente
• Comentários desatualizados: você renomeou a função, mas o comentário acima ainda fala no nome antigo
• Código morto: uma função que você escreveu e não usou, uma variável declarada e nunca lida
• Scope creep: mudanças que não têm relação com o objetivo do PR — uma refatoração extra que você fez "já que estava aqui"

Esse último é relevante porque scope creep silencioso é o que transforma PRs focados em PRs difíceis de revisar. Se você percebeu que fez uma mudança extra que faz sentido, vale criar um PR separado ou pelo menos documentar explicitamente na descrição.

PRs menores como consequência natural

Quando você olha o diff antes de abrir, você naturalmente se pergunta: "essa mudança no arquivo X tem relação com o que eu estou submetendo?" Se a resposta for não, você começa a separar.

Não é uma regra imposta — é um efeito colateral do hábito. O diff visual deixa o escopo concreto. É mais fácil defender "esse PR faz uma coisa" quando você acabou de olhar para ele e confirmou isso.

PRs menores têm review mais rápido, menos chance de conflito e histórico mais legível no git log. Não é novo — todo time sabe disso. O que o self-review faz é criar a pressão natural para respeitar esse princípio.

O hábito que vale cultivar

O processo é simples: antes de clicar em "Create pull request", abra o diff. Leia cada arquivo como se fosse o revisor. Corrija o que você encontrar. Só então abra o PR.

Não precisa ser longo. Diffs pequenos levam dois minutos. Diffs grandes — que já são um sinal de atenção — levam cinco ou dez. Em ambos os casos, o tempo gasto antes tende a ser menor que o tempo recuperado no ciclo de revisão.

É o tipo de hábito que depois que você adota, parece óbvio que não estava fazendo antes.

Nota: o conteúdo editorial acabou aqui. O que vem abaixo é uma indicação de ferramenta relacionada ao tema do post.

Ferramenta relacionada

Para revisar diffs fora do terminal — especialmente útil quando você está comparando versões de um arquivo copiado, comparando outputs de dois ambientes, ou revisando mudanças em contextos sem Git — uso o Comparador de Texto. Você cola as duas versões e vê as diferenças destacadas lado a lado, sem precisar de repositório ou CLI.