Navegando pelo hackernews hoje, me deparei com um post sobre comandos git úteis, e resolvi compartilhar aqui também.

O post original é The Git Commands I Run Before Reading Any Code

Comandos

Aqui embaixo coloco os comandos que o autor escreveu, e mais alguns que eu acho úteis.

Arquivos que mais mudam no projeto

Este comando lista os 20 arquivos que mais sofreram alterações no último ano (“churn”).

Por que é bom: Um arquivo com um histórico de mudanças frequentes nem sempre é um problema se for desenvolvimento ativo, mas se ele sofre alterações constantes e ninguém quer assumir a propriedade dele, é um forte indicativo de débito técnico. De acordo com estudos, arquivos com alta taxa de modificação (“churn”) são grandes previsores de defeitos na base de dados. Cruzar esta lista com a de arquivos problemáticos (como veremos abaixo) ajudará a encontrar grandes riscos técnicos no código.

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

Quem mais comittou no projeto

Aqui vemos o ranking de contribuidores organizados pela quantidade de commits efetuados.

Por que é bom: Entender quem mais trabalhou no projeto te mostra o seu “fator de ônibus” (bus factor). Se uma única pessoa for responsável por mais de 60% dos commits e ela já tiver saído ou deixado de contribuir recentemente, você pode estar diante de uma iminente crise de conhecimento. Observar essa cauda (os autores versus os últimos ativos em um ciclo de 6 a 12 meses) ajuda a entender se os criadores originais do sistema ainda são quem o mantém ativo.

git shortlog -sn --no-merges

Arquivos que mais tiveram bugs

Este comando varre os commits em busca de palavras-chave relacionadas a consertos ou quebras (como “fix”, “bug” ou “broken”) e lista os arquivos mais afetados por tais eventos.

Por que é bom: Se você cruzar a saída deste comando com a dos itens que mais mudaram, você encontrará as áreas de maior risco na base de código: os arquivos problemáticos da aplicação, que constantemente quebram com mudanças mas nunca recebem uma refatoração e correção definitivas. Apesar de basear-se na disciplina do seu time ao descrever commits (e de ser um mapa imperfeito) ainda é muito melhor do que não ter dados reais de falhas.

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

Commits por mês / Projeto acelerando ou morrendo

Mapeia e organiza a quantidade de commits realizados com base no mês ao longo de todo o histórico da aplicação.

Por que é bom: Com ele podemos rapidamente visualizar informações sobre o ritmo de desenvolvimento (velocity). Um projeto perfeitamente saudável terá um ritmo bem mais constante de contribuições. Porém, uma queda vertiginosa de ritmo entre meses, ou mesmo um declínio regular de 6-12 meses, reflete que a equipe provavelmente está perdendo momento ou até sofrendo com perdas cruciais de engenheiros na equipe técnica. Picos súbitos frequentes de commits revelam equipes que entregam grandes escopos no lugar da entrega contínua de código ágil.

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

Reverts e Hotfixes

Filtra e retorna os commits mais recentes (dentro do intervalo estipulado de um ano) e pesquisa apenas os marcados como alertas de código (com as palavras “revert”, “hotfix”, “emergency” ou “rollback”).

Por que é bom: A frequência com que seu time precisa reverter ou intervir demonstra fielmente e com segurança o quão instáveis as suas pipelines de CI/CD e de deploy são. Entregas muito estressantes ou intervenções de rollback quase semanais comunicam a todos os envolvidos que a base não possuí testes com precisão suficiente, não há um ambiente isolado de simulação de homologação (staging) eficaz e a entrega final do sistema continuará perigosa a cada novo release.

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