Git Things

Code review e fluxo de trabalho

• Algumas equipes adotam estilos como “ship/show/ask”, em que o autor escolhe quanta revisão é necessária, permitindo merges rápidos para mudanças pequenas e de baixo risco.
• Outras argumentam que a escolha do revisor deveria depender mais de quem entende o código afetado, e não apenas da confiança do autor.
• Uma proposta de “fazer merge de forma otimista” para main e revisar depois recebe resistência: críticos dizem que isso degrada a confiabilidade de main, remove a pressão social para revisar e priva pessoas juniores de aprendizado por meio de feedback antes do merge.
• Documentação e testes frequentemente travam PRs; entre as sugestões estão tratar a documentação como algo de primeira classe (PR não aceitável sem ela), escrever a documentação primeiro para esclarecer a intenção, ou deixar que revisores redijam a documentação inicial para expor lacunas.

Mensagens de commit e histórico

• Há forte discordância sobre mensagens no estilo “minor”/“fix”: alguns acham aceitáveis para mudanças muito pequenas; outros insistem que todo commit deve expressar intenção, especialmente para depuração com blame/bisect.
• Muitos querem ao menos contexto de alto nível no assunto (“o quê”), às vezes com um ID de ticket; outros argumentam que o mínimo deveria ser “por quê”, já que o diff já mostra o “o quê”.
• A diretriz de assunto com 50 caracteres é debatida: alguns a veem como arcaica e derivada de terminais antigos; outros defendem assuntos curtos para facilitar a leitura em ferramentas como log e blame. Ferramentas que impõem 50 caracteres são vistas como irritantes.
• Fazer squash versus preservar commits granulares: alguns preferem squash para reduzir ruído; outros argumentam que é possível simular uma “visão squash” com --first-parent e que squash destrói histórico útil.

Testes, testes falhando e bisect

• A recomendação de commitar primeiro um teste falhando e depois a correção é elogiada como TDD de baixa fricção e útil para revisão.
• Críticos observam que isso pode quebrar git bisect e as expectativas de CI se testes falhando chegarem a main.
• Uma sugestão relacionada de ajustar asserções para cristalizar o comportamento errado atual (com TODO) é amplamente criticada; vários argumentam que testes nunca devem impor comportamento incorreto e, em vez disso, deveriam ser marcados como expected-fail ou removidos.

Renomeações e rastreamento de histórico

• Alguns veem a detecção de renomeação baseada em conteúdo do Git como uma falha; querem metadados explícitos de movimentação (git mv registrado de forma robusta).
• Outros defendem o modelo atual, observando que ele permite rastrear histórico através de splits/merges de arquivos e movimentações mais granulares, embora de forma imperfeita; flags como git blame -C podem ajudar.
• Propostas para adicionar metadados explícitos de movimentação levantam preocupações sobre complexidade, suporte de ferramentas e conflitos de merge.

Comprimento de linha e convenções de ferramentas

• Limites de linha/assunto (80–120 para código, ~50–72 para assuntos de commit) são discutidos como mistura de artefato histórico e legibilidade prática: diffs lado a lado, laptops pequenos, olhos envelhecendo.
• Alguns defendem limites relaxados ou sem limites rígidos e deixar que as ferramentas façam a quebra; outros enfatizam que linhas mais curtas são mais fáceis de ler e que um limite suave também expõe expressões excessivamente complexas.

Ramificações: merge vs rebase

• Merge e rebase são vistos como ferramentas distintas: rebase para branches de funcionalidade compartilhadas e reescrita de histórico; merge para integrar trabalho e preservar commits originais.
• Alguns preferem merge commits como pontos explícitos onde a resolução de conflitos fica registrada; outros fazem rebase para evitar merge commits “cheios de dragões” e manter main linear para CI/bisect.