Antes de abrir qualquer arquivo em um novo código, o que costuma fazer é acessar o terminal e executar alguns comandos do Git. O histórico de commits oferece uma visão diagnóstica do projeto: quem o desenvolveu, onde os problemas estão concentrados e se a equipe está trabalhando com confiança ou evitando áreas problemáticas.

Um dos primeiros comandos que rodo é: "git log --format=format: --name-only --since='1 year ago' | sort | uniq -c | sort -nr | head -20". Isso revela os 20 arquivos que mais mudaram no último ano. O primeiro da lista costuma ser o mais temido pela equipe. Um arquivo que apresenta alta rotatividade pode indicar problemas, especialmente se ninguém quer assumir a responsabilidade por ele. Esse é o tipo de arquivo onde cada alteração é apenas um remendo em um remendo, tornando o impacto de pequenas mudanças imprevisível.

Ademais, utilizo o comando "git shortlog -sn --no-merges" para ver quem são os contribuintes do projeto, classificados pela contagem de commits. Se uma única pessoa representa 60% ou mais, isso indica um risco elevado, conhecido como "bus factor". Caso essa pessoa tenha saído há seis meses, a situação é crítica. Também analiso a lista dos contribuidores ativos, pois se apenas três de trinta estiverem contribuindo nos últimos doze meses, isso mostra que as pessoas que construíram o sistema não são as mesmas que o mantêm.

Outro comando importante é: "git log -i -E --grep='fix|bug|broken' --name-only --format='' | sort | uniq -c | sort -nr | head -20". Esse comando filtra os commits que contêm palavras-chave relacionadas a bugs e ajuda a identificar onde os problemas estão se acumulando. Comparo essa lista com a de arquivos mais alterados, pois aqueles que aparecem em ambas são os de maior risco.

Além disso, analiso a velocidade de commits ao longo do tempo com o comando "git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c". Isso me permite ver se o projeto está acelerando ou perdendo ímpeto. Um gráfico com quedas significativas pode indicar a saída de um membro importante da equipe, enquanto picos periódicos seguidos de meses silenciosos sugerem que a equipe está agrupando seu trabalho em lançamentos em vez de enviar continuamente.

Por fim, verifico a frequência de reverts e hotfixes com o comando "git log --oneline --since='1 year ago' | grep -iE 'revert|hotfix|emergency|rollback'". Um número baixo de reverts é normal, mas se houver reverts frequentes, isso indica que a equipe não confia no processo de deploy, o que pode ser um sinal de problemas mais profundos.

Esses cinco comandos podem ser executados em poucos minutos e, embora não ofereçam uma visão completa, permitem que eu identifique quais partes do código devem ser lidas primeiro e onde focar minha atenção. Essa abordagem proporciona uma análise mais eficiente e direcionada do código.