"Número de commits não diz nada." Essa é provavelmente a crítica mais comum a qualquer métrica de engenharia, e ela está meio certa. Commit isolado não prova qualidade, valor de produto nem senioridade. Mas descartá-lo por completo joga fora um sinal operacional valioso.
O que o commit realmente mede
Commit é um registro rastreável de alteração no código: mostra quem alterou, quando e onde. Como sinal de gestão, ele indica continuidade de trabalho técnico, não valor entregue. São coisas diferentes, e confundi-las é a origem da maioria das críticas.
Ficar vários dias sem commit, por outro lado, diz algo importante:
- risco de perda local de trabalho se a máquina falhar;
- retrabalho, porque colegas não enxergam a versão atual;
- integração tardia e conflitos descobertos tarde demais;
- baixa rastreabilidade do progresso para liderança e pares.
Commit frequente não é sobre parecer ocupado. É sobre reduzir risco operacional e manter o código sincronizado com o time.
E se alguém inflar a contagem?
No Devint, a faixa saudável de referência é de 3 a 10 commits por dia útil, com teto. Acima disso, mais commits não pontuam. E há um detalhe curioso: se alguém tenta "manipular" fazendo commits menores e mais frequentes, está se aproximando do comportamento desejado, com trabalho mais rastreável e fácil de revisar. Cinco pull requests de 50 linhas costumam ser operacionalmente melhores que um de 250.
A manipulação ruim, com fragmentos sem sentido, aparece nas outras dimensões: contribuição real baixa, problemas de revisão e avaliação técnica ruim.
A leitura certa
Microgerenciamento pergunta: "por que você não fez commit ontem?". Gestão saudável pergunta: "nas últimas semanas seu ritmo caiu; houve bloqueio, mudança de escopo ou problema de dados?".
Commits não dizem tudo. Mas ausência prolongada de commits diz algo importante, e é para capturar essa diferença que eles entram no DevScore como sinal de ritmo, combinados com contribuição, avaliações humanas e disciplina operacional.