Como fazer um bom commit?
Por que mensagens de commit importam, o padrão Conventional Commits e como escrever histórico de git que vale como portfólio.
Histórico de commits é a primeira coisa que um dev mais experiente olha quando abre seu repositório. Commits com mensagens como "fix", "ajustes", "teste" ou "wip" dizem mais sobre seus hábitos de trabalho do que você gostaria.
Um bom commit não é só boa prática: é parte do portfólio.
O problema com commits ruins
git log --oneline
a3f9c1 fix
b2e81d ajustes
c19a4f funcionou
d30f5e teste 2
e41b6a primeiro commit
Esse histórico não conta a história do que foi feito. Se algo quebrar em produção às 3h da manhã, ninguém vai conseguir entender o que mudou e quando.
O padrão: Conventional Commits
O padrão mais adotado no mercado é o Conventional Commits. A estrutura é:
<tipo>(<escopo opcional>): <descrição curta>
Tipos comuns:
| Tipo | Quando usar |
|---|---|
feat | Nova funcionalidade |
fix | Correção de bug |
docs | Mudança em documentação |
style | Formatação (sem mudança de lógica) |
refactor | Refatoração sem nova feature nem bug fix |
test | Adição ou correção de testes |
chore | Tarefas de manutenção (dependências, config) |
Exemplos:
feat(auth): adiciona login com Google OAuth
fix(cart): corrige cálculo de frete para CEPs do Norte
docs(api): adiciona exemplos de uso no README
refactor(users): extrai validação de email para helper
test(checkout): adiciona teste para pedido com cupom inválido
Regras práticas
Um commit, uma mudança. Cada commit deve fazer uma coisa. "Adiciona login e corrige bug no carrinho" são dois commits.
Presente, não passado. "adiciona" em vez de "adicionei". Pense no commit como instrução: "quando aplicado, este commit adiciona..."
Descrição curta no imperativo, sem ponto final. Menos de 72 caracteres. Se precisar explicar mais, use o corpo do commit (linha em branco depois da primeira linha).
Commit antes de estar perfeito é melhor que commit depois de dois dias. Commitar frequentemente é hábito de profissional. Commitar toda a feature em um bloco gigante dificulta revisão e debug.
Como fica na prática
# Ruim
git add .
git commit -m "ajustes"
# Bom
git add src/auth/google.js
git commit -m "feat(auth): implementa callback OAuth do Google"
git add src/auth/google.test.js
git commit -m "test(auth): adiciona teste para callback OAuth com token inválido"Git commit no portfólio
Quando um recrutador ou dev abre seu repositório e roda git log, commits bem escritos mostram que você:
- Tem disciplina de desenvolvimento
- Consegue comunicar mudanças com clareza
- Trabalha de forma que facilita colaboração
É um sinal simples de profissionalismo que diferencia portfólios.
- Meus commits descrevem o que foi feito de forma clara?
- Cada commit tem uma responsabilidade só?
- Estou usando um padrão consistente (Conventional Commits ou equivalente)?