Alguns desenvolvedores preferem revisão de código com "interdiff"

Por que algumas pessoas gostam de revisão de código com "interdiff"

Avaliando a ferramenta de revisão de código Gerrit

• Gerrit é uma ferramenta de revisão de código de código aberto que funciona com repositórios Git
• É possível criar patches no repositório e enviá-los para revisão
• Outras pessoas revisam o código escrito e apontam problemas que precisam ser corrigidos
• Revisão de código geralmente é uma boa ideia
• Em projetos de código aberto, o código pode ser mesclado, o que aumenta a responsabilidade e a dívida técnica

Diversas ferramentas de revisão de código

• Existem várias ferramentas, como Gerrit, GitHub, Phabricator, upload de arquivos .patch em rastreadores de bugs e envio por e-mail via git send-email
• Cada ferramenta pode funcionar em diferentes graus de eficácia

Série de patches ideal

• Uma série de 3 patches representa a evolução da base de código passo a passo
• As mudanças devem ser separadas logicamente, e cada patch deve poder ser lido como se tivesse sido aplicado individualmente
• A revisão de código analisa essa série ideal

A forma de revisão de código do GitHub: "diff soup"

• O GitHub originalmente incentiva revisões adicionando novos commits por cima dos commits existentes
• Isso acontece por causa do design de UX e por vários outros motivos
• Quando vários commits são adicionados durante o processo de revisão, as relações implícitas entre eles ficam complexas
• Isso dificulta o uso das ferramentas git blame e git bisect

Um método melhor: revisão com "interdiff" (também conhecida como git range-diff)

• Em vez de adicionar novos commits, publica-se uma nova versão dos commits originais
• Usa-se git range-diff para comparar as diferenças entre versões dos commits
• O revisor pode fazer uma revisão incremental sem precisar reler todo o diff
• As ferramentas git blame e git bisect funcionam de forma mais confiável

Explicação intermediária: estratégia de mesclagem de patches

• O método acima é independente da estratégia de mesclagem (por exemplo, git rebase vs commit git merge com múltiplos pais)

Explicação intermediária: se git rebase é algo ruim

• git rebase é aceitável. Só não deve ser usado em branches públicas sobre as quais outras pessoas basearão seus commits

Outras notas

Conclusão

• O sistema de revisão com interdiff incentiva patches menores e que são mesclados mais rapidamente na branch principal
• Ele oferece uma experiência de revisão de código melhor tanto para revisores quanto para autores

Resumo do GN⁺

• Este artigo oferece uma análise aprofundada sobre ferramentas e metodologias de revisão de código
• A abordagem de revisão com interdiff pode melhorar bastante a eficiência da revisão de código
• Ela ajuda a resolver o problema de "diff soup" do GitHub
• O texto apresenta fatores importantes a considerar ao escolher uma ferramenta de revisão de código
• Ferramentas com recursos semelhantes incluem GitHub, Gerrit e Phabricator

[GN⁺]

Comentários do Hacker News

• O fluxo de trabalho usado principalmente no GitHub envolve muito trabalho e não é claro para os colaboradores

  • Permite que o revisor veja a diferença com o feedback incorporado sem quebrar git blame e git bisect
  • Ao incorporar o feedback do revisor, usa-se git commit --fixup <hash do commit a ser atualizado>
  • Quando o PR é aprovado, usa-se git rebase --interactive origin/main --autosquash para combinar os commits de fixup com os commits originais
  • Por fim, faz-se o merge usando git push --force-with-lease
  • Usa-se o recurso de autocompletar para digitar comandos longos com facilidade

• A forma de revisão de código do GitHub é ineficiente, e isso era tratado manualmente com o Phabricator

  • Seria melhor se houvesse uma UI explícita

• Querem um sistema melhor do que a forma de revisão de código do GitHub

  • Querem mesclar rapidamente patches pequenos de correção de bugs e reduzir o escopo da revisão
  • Há quem diga para criar uma revisão/PR separada, mas isso gera problemas de dependência entre patchsets

• É sempre interessante ver novas abordagens para revisão de código

  • Já consideraram dividir patches em PRs dependentes separados
  • Ferramentas como GitContext podem ajudar a manter os PRs pequenos enquanto preservam as dependências
  • É possível usar IA para resumir PRs e revisões e gerar mensagens de commit precisas
  • O revisor pode ver apenas as mudanças desde a última revisão

• O Review Board introduziu interdiffs primeiro, e isso é muito útil em revisão de código

  • Commits de fix-it não são uma alternativa adequada
    1. Não mostram as mudanças upstream
    2. Tornam o grafo de commits mais complexo
    3. Nem todo mundo usa Git
  • Interdiffs permitem que o revisor acompanhe todas as atualizações desde a primeira solicitação de revisão
  • São úteis ao publicar vários commits como uma única solicitação de revisão

• Já usaram o sistema de revisão de código Gerrit, e a revisão de código do GitHub é ineficiente

  • O Gerrit suporta empilhar vários patches, o que facilita revisar patches pequenos
  • A interface do GitHub parece um tópico de fórum e não consegue acompanhar rebases

• Já usaram vários sistemas de revisão de código, e cada um tem seus pontos fortes e fracos

  • O Critique é otimizado para o monorepo do Google e seu VCS personalizado
  • O Gerrit é bom para revisores, mas inconveniente para autores
  • O GitHub é amigável para autores, mas ineficiente para revisores e equipes
  • É importante usar ferramentas melhores de revisão de código

• Depois de usar o sistema de revisão de código Gerrit, os PRs em pilha do GitHub parecem incômodos

  • O GitHub não mostra direito as alterações relacionadas aos comentários na revisão de código
  • Usam alguns scripts para facilitar o trabalho com PRs em pilha
  • Ferramentas como ejoffe/spr e spacedentist/spr são úteis