Git além do commit e push — o que aprendi trabalhando em time
Eu sabia usar Git solo. Aprendi a usar Git em time quando comecei a entender que o histórico de commits é comunicação, não só rastreamento.
Usei Git solo por anos antes de trabalhar em time de verdade.
Solo, Git era uma ferramenta de backup com viagem no tempo. Commit quando achava que tinha algo, push para não perder, revert quando algo dava errado. O histórico era irrelevante — eu era a única pessoa que ia ler.
Quando comecei a trabalhar com outros devs, essa visão não durou muito tempo. O histórico passou a importar. Os commits passaram a ser lidos por outras pessoas. As branches passaram a ser uma forma de coordenação, não só organização pessoal.
A primeira coisa que mudou foi entender commits como mensagens, não só marcadores.
Um commit com a mensagem "fix" não comunica nada para quem vai ler o histórico amanhã, ou em seis meses, tentando entender por que uma mudança foi feita. Um commit com "fix: corrige cálculo de desconto quando o cliente tem múltiplos cupons ativos" comunica o problema, o contexto, e o escopo da mudança.
Commits atômicos — onde cada commit representa uma mudança coesa e completa — tornam o histórico navegável. Você consegue encontrar quando uma funcionalidade foi introduzida. Você consegue entender o que foi alterado em cada passo. Você consegue fazer revert de uma mudança específica sem afetar outras.
Commits misturados — onde uma mudança no banco de dados, uma correção de bug não relacionada, e uma melhoria de UI estão no mesmo commit — tornam o histórico um arquivo de trabalho que ninguém consegue usar de verdade.
Branches são contratos.
Em projetos solo, eu usava branches como rascunhos. Em time, a branch é uma comunicação de intenção: "estou trabalhando nessa funcionalidade, isso é o que vai entrar em main quando estiver pronto."
O nome da branch importa. feature/payment-webhook-retry é uma branch. my-fix não é uma branch, é um rascunho nomeado.
A duração da branch importa. Branches de vida longa acumulam divergência de main. Quando você vai mergar, o trabalho de conciliação pode ser maior do que o trabalho original. A preferência por branches curtas, PRs pequenos, e integração frequente não é preferência estética — é gerenciamento de risco.
Aprendi rebase na mão dura.
Minha primeira tentativa de fazer git rebase main numa branch com dez dias de trabalho resultou em dezenas de conflitos, um histórico confuso, e um colega que precisou me ajudar a sair da situação.
O que eu não entendia: rebase reescreve o histórico. Cada commit da sua branch é reaplicado sobre o tip de main, um por vez. Se main mudou muito durante os dez dias, cada commit vai potencialmente ter conflitos com as mudanças de main.
A solução não é evitar rebase — é fazer rebase mais frequentemente. Toda vez que main avança com mudanças que afetam seu trabalho, fazer rebase antes que a divergência cresça demais. Pequenas atualizações frequentes são mais fáceis do que uma grande reconciliação.
git bisect foi a ferramenta que mais me impressionou quando descobri.
O problema: um bug apareceu em produção que não estava lá há duas semanas. Você não sabe em qual commit foi introduzido. Procurar manualmente entre cinquenta commits seria demorado.
git bisect faz busca binária no histórico. Você diz qual é o commit bom mais recente que conhece e qual é o commit ruim mais recente. Ele divide o intervalo ao meio e pergunta se esse commit é bom ou ruim. Você testa, responde, ele divide de novo. Em poucos passos, você chega no commit exato que introduziu o problema.
Essa semana: olhe para os últimos dez commits no projeto que você trabalha. Se você não consegue entender o que cada um fez sem abrir o diff, os commits estão grandes ou mal descritos demais. Experimente escrever o próximo commit como se fosse uma mensagem para um colega que vai precisar entender essa mudança em seis meses.