Todo mundo sabe rodar git commit. Pouca gente comita bem. E a diferença não aparece hoje — aparece daqui a seis meses, quando você dá git blame numa linha bugada e encontra a mensagem eterna: "ajustes finais". Git não é backup. É ferramenta de comunicação com o time, e o time inclui você mesmo no futuro.
Commit pequeno é presente pro seu eu do futuro
Um bom commit faz uma coisa só. Renomeou uma função? Um commit. Corrigiu o bug de timeout? Outro commit. Ajustou a indentação? De preferência, nem commita junto.
O problema do commit gigante que mistura refactor, correção e formatação não é estético. É prático: quando aquele bug voltar em produção, você vai querer dar git revert só na correção — e não vai conseguir, porque ela está grudada em outras 400 linhas de mexida.
Commits atômicos deixam o git bisect viável, o git revert cirúrgico e o histórico legível. Regra de bolso: se pra descrever o commit você precisa de um "e", provavelmente são dois commits.
Mensagem boa: imperativo na primeira linha, o porquê no corpo
A primeira linha resume, curta (uns 50 caracteres) e no imperativo — como se completasse a frase "se aplicado, este commit vai...": "Corrige timeout no upload de imagem". Não "corrigido", não "corrigindo". O próprio Git usa imperativo nas mensagens automáticas; siga o padrão.
Depois, uma linha em branco e o corpo. E aqui vai o que separa mensagem boa de mensagem inútil: o corpo explica por que, não o quê. O diff já mostra o que mudou. O que ele não mostra é que você trocou a biblioteca porque a antiga estourava memória acima de 2 MB. Isso é o que alguém — talvez você — vai precisar saber depois.
Branch curta, PR pequeno, review rápido
Branch que vive duas semanas vira um festival de conflitos no dia do merge. Quanto mais tempo ela fica longe da main, mais o mundo muda embaixo dela.
Fatie a tarefa. Cada branch deveria durar horas ou poucos dias, não semanas. E o mesmo vale pro PR: um de 200 linhas recebe review de verdade, com gente lendo linha a linha. Um de 2000 linhas recebe um "LGTM" e um emoji de foguete — porque ninguém revisa 2000 linhas de sábado à tarde. PR pequeno não é burocracia; é a única forma de review honesto acontecer.
Rebase ou merge: depende de quem vai ler o histórico
Os dois integram mudanças, mas contam histórias diferentes. merge preserva o que aconteceu de verdade, com o commit de merge marcando onde as linhas se juntaram. rebase reescreve sua branch como se você tivesse começado a partir do estado mais recente — histórico linear, limpo, sem os "merge branch main into main" poluindo o log.
Na prática: use rebase pra arrumar a sua branch local antes de abrir o PR — atualizar com a main, esmagar os "fix typo" em um commit decente. Use merge pra trazer a branch revisada pra main.
E a regra que não tem exceção: nunca faça rebase de algo que já foi publicado e que outra pessoa pode ter puxado. Rebase reescreve hashes; se o commit já é público, você acabou de criar duas histórias divergentes e um git push --force que vai arruinar a manhã de alguém.
Conflito não é briga — resolva com calma
Conflito assusta na primeira vez porque o Git despeja aqueles <<<<<<< no meio do arquivo e parece que tudo quebrou. Não quebrou. O Git só está dizendo: "duas pessoas mexeram aqui, decide você".
Respira. git status lista exatamente quais arquivos precisam de atenção. Abra um por vez. Entre os marcadores estão as duas versões: a sua e a que veio. Leia as duas — o objetivo não é escolher um lado no braço, é entender o que cada mudança queria fazer e produzir uma versão que contemple ambas. Apagou os marcadores, testou, git add, segue. Pressa aqui é como você sobrescreve o trabalho de alguém sem perceber.
O que NUNCA entra no repositório
Uma regra curta e inegociável: segredo não versiona. Nada de .env, chave de API, token, credentials.json. Coloca tudo no .gitignore antes do primeiro commit, não depois — porque "depois" já é tarde. Segredo que entrou no histórico continua lá mesmo se você apagar o arquivo no commit seguinte; qualquer um com o repo dá git log e acha.
Fora segredos, não versione o que dá pra regenerar: node_modules, dist/, build/, .DS_Store, logs. Isso não é código — é ruído que incha o repo e gera conflito à toa.
Git bom não é sobre decorar comando. É sobre lembrar que tem gente do outro lado lendo o que você deixou. Comita pequeno, escreve o porquê, e trata o .gitignore com o mesmo carinho que trata o código. Seu eu de daqui a seis meses vai te agradecer — ou te xingar. A escolha é sua, um commit de cada vez.
