Por Que Mudei Meu Jeito de Committar
No início, eu usava o Git como se fosse um sistema de backup. Codava por horas e depois jogava tudo em um único commit: “WIP”, “fix”, ou pior—sem mensagem nenhuma. Eu não pensava em termos de unidades de mudança. Pensava no tempo que tinha passado. O Git não me ajudava a colaborar ou entender meu código; era só um lugar pra estacionar.
Isso começou a mudar quando entrei num projeto com revisões mais rigorosas. Meus commits gigantes eram difíceis de entender, e os revisores tinham dificuldade em acompanhar. Fui forçado a desacelerar e pensar: o que exatamente mudei aqui, e por quê?
Descobri que fazer commits pequenos e significativos não era apenas um favor aos revisores—me tornava um desenvolvedor melhor. Eu encontrava bugs mais rápido, revertia mudanças arriscadas com mais segurança e entendia meu próprio código com mais clareza.
O Git deixou de ser uma ferramenta passiva e virou parte ativa da minha prática. Cada commit passou a ser uma decisão de design.
Vamos explorar essa mudança de mentalidade e os hábitos concretos que surgiram dela.
Commits Como Comunicação
Um commit não é só um registro de mudança—é uma mensagem para seu “eu do futuro” e para seu time. Quando são pequenos e bem definidos, contam uma história. Uma história que pode ser lida, revisada e até reescrita com intenção.
git add src/modulo.js
git commit -m "Adiciona validação para campos vazios"
Compare com:
git commit -am "grandes mudanças"
O primeiro exemplo é claro. O segundo é ruído. E ruído atrapalha.
| Estilo de Commit | Clareza | Segurança de Reversão | Dificuldade de Revisão |
|---|---|---|---|
| Pequeno e focado | Alta | Fácil | Baixa |
| Grande e vago | Baixa | Arriscado | Alta |
Quando passei a ver o commit como uma ferramenta de comunicação, tudo mudou. Comecei a dividir as mudanças em unidades lógicas—um bug fix, um refactor, uma melhoria por commit. Exigiu disciplina, mas valeu a pena.
Os revisores davam feedback mais direto. Eu errava menos. E quando algo dava errado, eu localizava o problema com git bisect.
Construindo o Hábito
Mudar minha forma de committar não foi fácil. Requereu mudança de ritmo e de mentalidade. No início, eu precisava me lembrar de pausar. De refletir sobre o que tinha mudado. De pensar antes de digitar git commit.
Comecei a usar git diff com git add -p:
git diff
git add -p
Isso me dava visibilidade das mudanças e permitia stagear apenas o que fazia sentido. Em vez de pensar “terminei minha tarefa?”, comecei a pensar “qual unidade de valor eu completei?”
| Prática | Benefício |
|---|---|
git add -p | Permite stage interativo |
| Commits frequentes | Facilita rollback e revisão |
| Mensagens claras | Aumenta entendimento do time |
Também comecei a escrever mensagens de commit como títulos curtos. Ação + intenção. Por exemplo: Refatora serviço de usuário para reduzir duplicação.
Com o tempo, virou hábito. Não precisava mais pensar tanto—simplesmente trabalhava em incrementos pequenos e limpos.
Esse hábito me deixou mais rápido, não mais lento. Porque debug e revisão ficaram quase triviais.
Conclusão: A Disciplina Que Compensa
Muitos desenvolvedores resistem a fazer commits pequenos porque acham que dá mais trabalho. Mas a verdade é que o tempo economizado depois—em revisões, investigação de bugs ou blame—compensa muitas vezes o esforço.
Commits pequenos estimulam foco. Forçam a quebrar o trabalho em partes gerenciáveis. E se alinham com a forma como deveríamos pensar software: como uma série de mudanças pequenas e pensadas que constroem algo maior.
Então, da próxima vez que for juntar tudo num commit só, pare. Pergunte-se: o que estou tentando comunicar com essa mudança? Quem vai ler isso depois?
Escreva seu histórico como se alguém fosse depender dele. Porque um dia, vai. E essa pessoa pode ser você mesmo.