Todo mundo aprende (via documentação oficial do Git) git add, git commit e git push cedo. O que faz diferença no dia a dia não é conhecer mais comandos — é ter um fluxo consistente, que funcione tanto sozinho quanto em equipe, sem depender de memória para lembrar convenção.
Meu fluxo em projetos solo
Mesmo trabalhando sozinho, como no Simulado Solidário, uso branches por funcionalidade e mensagens de commit que expliquem o porquê da mudança, não só o que mudou. Isso parece burocracia desnecessária para um projeto de uma pessoa só — até o dia em que preciso entender, seis meses depois, por que uma decisão foi tomada daquele jeito.
Uma mensagem de commit como "corrige bug" não me diz nada seis meses depois. Uma mensagem como "corrige duplicidade de e-mail quando o webhook do gateway reenvia a mesma confirmação de pagamento" me devolve o contexto inteiro sem eu precisar reconstruir o raciocínio do zero. O tempo extra para escrever isso é insignificante perto do tempo que economiza depois.
O que muda em equipe
Em projetos com mais de uma pessoa, o cuidado extra vai para commits pequenos e revisáveis, e para nunca reescrever histórico já compartilhado. Rebase e squash têm seu lugar, mas só antes de compartilhar — depois disso, forçar histórico vira fonte de conflito desnecessário. Git, no fim, é sobre comunicação entre versões do código tanto quanto é sobre versionamento em si.
Documentação como parte do fluxo
Um bom histórico de commits funciona como uma forma de documentação viva — a mesma disciplina que aplico ao nomear funções, descrita em Clean Code não é sobre estética. Ambos existem para a mesma finalidade: reduzir o tempo que alguém (inclusive eu) leva para entender uma decisão passada.
