Abre o repositório novo, clona, dá aquele ls e já sai lendo código. Todo mundo faz isso. E todo mundo perde tempo fazendo isso.

Eu já entrei em projetos com 200 mil linhas de código e passei semanas tentando entender a arquitetura antes de perceber que o git log me contava tudo que eu precisava saber — sem abrir um único arquivo. Os commits são um diário involuntário do projeto. Cada merge, cada hotfix, cada refactor conta uma história. E a maioria dos devs ignora isso completamente.

O que eu vou mostrar aqui são 5 comandos que rodam em segundos e te dão um raio-x completo de qualquer codebase. Funciona pra projeto pessoal, pra aquele monolito legado da empresa, ou pra avaliar se vale a pena contribuir com um open source. Depois que você incorporar esses comandos no seu workflow, nunca mais vai abrir código às cegas.

O arquivo que todo mundo tem medo de mexer

Esse é o primeiro e mais revelador comando da lista:

git log --format=format: --name-only --since="1 year ago" \
  | sort | uniq -c | sort -nr | head -20

O que ele faz? Lista os 20 arquivos mais modificados no último ano, ordenados por quantidade de alterações.

Um exemplo real de output:

Quando um arquivo aparece com 847 modificações em 12 meses, isso grita: aqui tem problema. Pode ser código mal projetado que precisa de ajustes constantes. Pode ser uma classe God Object que acumulou responsabilidades demais. Ou pode ser simplesmente o coração do sistema — o que também é uma informação valiosa.

A sacada é cruzar dados. Se payment.go lidera o churn e é onde os bugs aparecem (spoiler: vamos checar isso no comando 3), você encontrou o ponto mais frágil do projeto sem ler uma linha de código.

Variação útil: churn por diretório

Se o repositório é grande demais e você quer uma visão macro:

git log --format=format: --name-only --since="1 year ago" \
  | sed 's|/[^/]*$||' | sort | uniq -c | sort -nr | head -10

Isso agrupa por diretório em vez de arquivo individual. Útil pra identificar qual módulo do sistema dá mais trabalho.

Quem manda nesse código? (E o que acontece se essa pessoa sair)

git shortlog -sn --no-merges

Output típico:

  1847  Maria Silva
   923  João Santos
   412  Carlos Lima
    87  Ana Ferreira
    12  Bot-CI

Esse comando revela o bus factor do projeto — quantas pessoas precisam ser atropeladas por um ônibus pra projeto parar. Se Maria Silva tem o dobro de commits de todo mundo combinado, o projeto tem um problema sério de concentração de conhecimento.

Mas tem nuance aqui. Número bruto de commits não conta a história toda. Alguém com 1847 commits pode estar fazendo micro-ajustes em configs, enquanto alguém com 87 commits pode ter escrito o core inteiro do sistema. Por isso, combine com esse outro comando:

git log --author="Maria Silva" --shortstat --no-merges \
  | grep "files changed" | awk '{ins+=$4; del+=$6} END {print "+" ins, "-" del}'

Isso te dá o total de linhas adicionadas e removidas por aquela pessoa. Agora sim você tem uma imagem mais completa.

O que fazer com essa informação?

• Bus factor = 1: Risco altíssimo. Se você está avaliando um projeto open source pra usar em produção, pense duas vezes.
• Contribuidores originais sumiram: Se quem começou o projeto não contribui mais, pergunte por quê. Burnout? Empresa mudou de stack? Fork?
• Muitos contribuidores com poucos commits: Pode indicar alta rotatividade na equipe — outro sinal de alerta.

O mapa dos bugs: onde o código quebra com mais frequência

git log -i -E --grep="fix|bug|broken|hotfix|patch|crash|error" \
  --name-only --format='' \
  | sort | uniq -c | sort -nr | head -20

Esse comando filtra commits cujas mensagens contêm palavras como “fix”, “bug”, “broken”, “hotfix” — e lista os arquivos mais afetados. É basicamente um mapa de calor de bugs.

Quando você cruza essa lista com o resultado do comando 1 (churn), os arquivos que aparecem em ambas as listas são os pontos críticos do projeto. É ali que mora o código mais perigoso, mais instável e mais caro de manter.

Eu já vi esse padrão em dezenas de projetos. Quase sempre, os 3-5 arquivos no topo dessa lista concentram 40-60% dos bugs do sistema. O Princípio de Pareto aplicado a código: 20% dos arquivos causam 80% dos problemas.

Indo mais fundo: bugs por autor

Quer saber quem tá gerando mais fixes? (Cuidado com como você usa essa informação — não é pra blame game.)

git log -i -E --grep="fix|bug" --format='%aN' \
  | sort | uniq -c | sort -nr | head -10

Isso mostra quem mais comita correções de bugs. Na maioria das vezes, é a mesma pessoa que mais contribui — o que é esperado. Mas se alguém com poucos commits totais lidera a lista de bug fixes, pode indicar que essa pessoa é o “bombeiro” do time, sempre apagando incêndio dos outros.

O pulso do projeto: está vivo ou em coma?

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

Output:

    45 2024-01
    52 2024-02
    67 2024-03
    89 2024-04
    92 2024-05
    78 2024-06
    34 2024-07
    12 2024-08
     8 2024-09
     3 2024-10

Esse gráfico (mental) mostra a velocidade do projeto ao longo do tempo. No exemplo acima, o projeto cresceu até maio, começou a desacelerar em julho e basicamente morreu em outubro. Clássico padrão de projeto que perdeu funding ou mudou de prioridade.

O que procurar:

Variação: commits por dia da semana

git log --format='%ad' --date=format:'%A' | sort | uniq -c | sort -nr

Isso revela os hábitos do time. Se sábado e domingo lideram, ou a equipe é muito dedicada, ou tem gente fazendo deploy na sexta de noite e passando o fim de semana consertando (pior cenário).

O detector de pânico: reverts, hotfixes e rollbacks

git log --oneline --since="1 year ago" \
  | grep -iE 'revert|hotfix|emergency|rollback|urgent|ASAP'

Esse é o comando que ninguém quer rodar. Porque ele mostra o nível de caos do projeto.

Cada revert é um deploy que deu errado. Cada hotfix é um bug que passou por code review, testes, staging e mesmo assim chegou em produção. E cada emergency é alguém acordando às 3 da manhã.

Um projeto saudável tem talvez 2-5 reverts por ano. Se você encontrar 30+, tem algo estruturalmente errado: testes insuficientes, reviews superficiais, ou pressão por velocidade que sacrifica qualidade.

Padrões temporais de caos

Combine com datas pra ver quando o pânico acontece:

git log --format='%ad %s' --date=format:'%Y-%m-%d %H:%M' \
  --since="1 year ago" | grep -iE 'revert|hotfix|emergency'

Se os hotfixes se concentram nas sextas-feiras à noite ou segundas de manhã, o processo de deploy precisa de atenção urgente. Ninguém deveria estar fazendo hotfix às 23h de uma sexta.

O combo final: frequência de rollbacks vs deploys

Se o time usa tags pra marcar releases:

# Total de releases
RELEASES=$(git tag -l "v*" --sort=-creatordate | head -20 | wc -l)

# Total de rollbacks/reverts
ROLLBACKS=$(git log --oneline --since="1 year ago" | grep -ciE 'revert|rollback')

echo "Releases: $RELEASES | Rollbacks: $ROLLBACKS | Taxa de falha: $(( ROLLBACKS * 100 / RELEASES ))%"

Uma taxa de falha acima de 15% é preocupante. Acima de 30% é sinal de que o pipeline de CI/CD precisa de uma revisão séria.

Juntando tudo: o diagnóstico completo em 30 segundos

Eu criei um alias que roda todos esses comandos de uma vez. Adiciona no seu .gitconfig:

[alias]
    diagnose = "!f() { \
        echo '=== TOP 10 CHURN ==='; \
        git log --format=format: --name-only --since='1 year ago' | sort | uniq -c | sort -nr | head -10; \
        echo ''; \
        echo '=== BUS FACTOR ==='; \
        git shortlog -sn --no-merges | head -5; \
        echo ''; \
        echo '=== BUG HOTSPOTS ==='; \
        git log -i -E --grep='fix|bug|broken' --name-only --format='' | sort | uniq -c | sort -nr | head -10; \
        echo ''; \
        echo '=== COMMIT VELOCITY (last 6 months) ==='; \
        git log --format='%ad' --date=format:'%Y-%m' --since='6 months ago' | sort | uniq -c; \
        echo ''; \
        echo '=== PANIC INDICATORS ==='; \
        git log --oneline --since='1 year ago' | grep -ciE 'revert|hotfix|emergency|rollback'; \
    }; f"

Agora basta rodar:

git diagnose

E em 30 segundos você tem o raio-x completo do projeto.

O bônus: git blame com contexto (pare de usar errado)

A maioria dos devs conhece o git blame, mas usa de forma primitiva. O comando básico mostra quem alterou cada linha, mas sem contexto isso é inútil — porque frequentemente quem fez a última alteração só estava refatorando ou movendo código.

O truque é usar as flags que ninguém conhece:

# Ignora whitespace changes
git blame -w arquivo.py

# Detecta linhas movidas de outros arquivos
git blame -C arquivo.py

# Detecta linhas movidas E copiadas de qualquer arquivo no mesmo commit
git blame -C -C arquivo.py

# O modo "forense total" — detecta cópias de QUALQUER commit
git blame -C -C -C arquivo.py

Cada -C adicional amplia o escopo de detecção. Com três -C, o Git vai rastrear a origem real de cada linha mesmo que ela tenha sido copiada de outro arquivo há 6 meses. É a diferença entre descobrir quem moveu a linha e quem realmente a escreveu.

Outra combinação poderosa:

# Blame mostrando a data do commit ao invés do hash
git blame --date=relative arquivo.py

Quando você vê que uma linha foi alterada “3 years ago”, sabe que é código estável. Quando vê “2 days ago”, sabe que é código fresco — e potencialmente instável. Essa informação é ouro durante debugging.

Além do git log: ferramentas que automatizam essa análise

Se você quer ir além dos comandos manuais, existem ferramentas que transformam esses dados em visualizações:

• git-of-theseus — Gera gráficos de stack mostrando a evolução da codebase ao longo do tempo. Quem escreveu o código que ainda está em produção?
• Hercules — Análise de burndown por arquivo e autor. Mostra quanto código de cada dev sobreviveu ao longo do tempo.
• git-quick-stats — Uma coleção de scripts que geram estatísticas detalhadas do repositório.
• code-forensics — Baseado nas ideias do livro Your Code as a Crime Scene de Adam Tornhill. Analisa acoplamento lógico, complexidade e churn.

O livro do Adam Tornhill, aliás, é leitura obrigatória pra quem se interessou por esse tema. Ele foi o primeiro a popularizar a ideia de tratar repositórios Git como cenas de crime — onde os commits são as evidências e os padrões revelam onde o código vai falhar a seguir.

Quando usar esses comandos na prática

Não é só pra quando você entra num projeto novo. Eu rodo esses comandos regularmente:

• Antes de um code review grande: Pra entender o histórico do arquivo que está sendo modificado
• No planning de sprint: Pra argumentar com dados quando digo “esse módulo precisa de refactor”
• Avaliando dependências open source: Se o projeto que você quer usar tem bus factor 1 e commits declinando, talvez valha procurar alternativas
• Entrevistas técnicas: Se te dão acesso a um repo e pedem pra avaliar a qualidade, esses comandos impressionam mais que qualquer análise superficial

A real é que a maioria dos devs trata o Git como um sistema de backup glorificado. Commit, push, merge, repeat. Mas o histórico do Git é uma das fontes de dados mais ricas sobre a saúde de um projeto de software — e quase ninguém explora isso.

Da próxima vez que você clonar um repositório, resista à tentação de abrir o código imediatamente. Roda um git diagnose primeiro. Os números vão te dizer exatamente onde olhar — e onde evitar.

Fonte de inspiração: Git commands I run before reading any code — trending #1 no Hacker News

👉 Leia também:
• Vibe Coding Gerou 69 Vulnerabilidades em 15 Apps — E Ninguém Revisou o Código
• Claude Encontrou um Bug no Linux que Ninguém Viu por 23 Anos