Crie mundos. Faça as ideias surgirem. Escreva todos os dias.
Origem e por que o histórico importa
Git guarda o estado do código, mas a mensagem de commit é o que transforma esse estado em narrativa. Em projetos pequenos, mensagens vagas passam, porém com o tempo o log vira ferramenta de debug, auditoria e onboarding. O formato clássico é um assunto curto e, opcionalmente, um corpo que explica o porquê. Conventional Commits adiciona um prefixo com tipo, como feat ou fix, às vezes com scope. Bem aplicado, isso pode alimentar changelogs e ajudar em versionamento semântico, desde que o time mantenha consistência.
Como escolher e usar uma mensagem útil
Escreva o assunto como uma ação
Assuntos fortes usam o imperativo: adicionar, corrigir, remover, ajustar. Assim a frase continua clara em uma lista de commits. Se você precisar explicar contexto, faça isso no corpo: restrições, riscos, alternativas e o motivo da decisão. O corpo também é um bom lugar para registrar impactos em dados, compatibilidade e passos de migração.
Use estrutura quando ela traz ganho real
O padrão type(scope): assunto organiza o histórico. O tipo diz a natureza da mudança, o scope indica a área e o assunto resume o resultado. Você pode incluir footers para breaking changes e referências. O objetivo não é parecer rígido, e sim ganhar velocidade. Poucos tipos e scopes estáveis ajudam revisões e releases. Regras demais tendem a virar burocracia e ruído.
Humor com clareza
Uma piada pode aliviar o clima, mas o log é um artefato de trabalho. Em repositórios compartilhados, o melhor é que a mensagem divertida ainda explique o que foi feito. Se você vai fazer squash, pode ser mais solto nos commits intermediários e reescrever o commit final antes do merge. Se você mantém todos os commits, trate cada assunto como um título que alguém vai procurar no futuro.
Identidade do time em uma linha
Mensagens de commit também mostram cultura. Assuntos claros reduzem carga mental em review e facilitam entender decisões e autoria. Um histórico cheio de "wip" passa a sensação de que detalhes não importam. Um histórico com mensagens úteis transmite respeito por tempo e contexto. Em times distribuídos, o log é comunicação assíncrona: ele explica uma mudança para alguém que não participou da conversa original.
Dicas para escrever melhor
- Quando possível, mantenha um objetivo coerente por commit para ficar específico.
- Use tipos e scopes apenas se seu time realmente adotar o padrão.
- Coloque o porquê no corpo: riscos, tradeoffs e alternativas rejeitadas.
- Referencie tickets no corpo ou footer, sem poluir o assunto.
- Antes do merge, limpe a branch: reword, squash e remova ruído.
- Leia o assunto isolado; se ele faz sentido, está pronto.
Perguntas para gerar ideias
Use estas perguntas para descobrir o verbo e o resultado que o diff realmente mostra.
- Qual comportamento visível mudou e qual verbo descreve isso melhor?
- Que área do projeto foi afetada e um scope estável ajudaria a revisar?
- Foi correção, proteção contra erro, ou simplificação do design?
- O que quebraria se você revertesse este commit amanhã?
- Qual tradeoff você aceitou: performance, legibilidade, compatibilidade?
- Qual é o assunto mais curto que continua honesto e útil?
Perguntas frequentes
Veja as dúvidas mais comuns sobre o gerador de mensagens de commit e como escrever mensagens de commit fáceis de entender em um histórico do Git lotado.
O que torna um assunto de commit bom?
Comece com um verbo no imperativo, seja específico e descreva a mudança. Se o assunto faz sentido sozinho no log, ele geralmente está no caminho certo.
Vale a pena usar Conventional Commits?
Ajuda quando você automatiza changelog e versão, porque os tipos podem ser processados. Se a regra não traz clareza, um estilo livre e consistente funciona melhor.
Quando devo usar um scope como feat(api)?
Quando o repositório tem várias áreas e você quer bater o olho e entender onde mexeu. Mantenha scopes curtos e estáveis para não virar ruído.
Como referenciar tickets e issues?
Coloque "refs #123" ou a chave do seu tracker no corpo ou no footer. O assunto fica limpo e o contexto continua rastreável durante o review.
Como corrigir uma mensagem ruim depois do commit?
Para o último commit, amend costuma resolver. Para commits anteriores na sua branch, um rebase interativo permite reescrever mensagens antes do merge. Evite reescrever histórico em branches compartilhadas.
O que são bons ideias de commit?
Existem milhares de ideias de commit aleatórios neste gerador. Aqui estão algumas amostras para começar:
- fix(ui): add rate limit backoff
- feat(cache): implement api error handling
- perf(tests): guard audit trail
- simplify routing table for slow networks
- guard rate limit backoff under load
- tighten audit trail (refs #1217)
- remove render pipeline for windows
- add rate limit backoff (refs #1522)
- wire feature flag toggle for staging
- ship it render pipeline and pretend it was intentional
Sobre o criador
Todos os geradores de ideias e ferramentas de escrita no The Story Shack são cuidadosamente criados pelo contador de histórias e desenvolvedor Martin Hooijmans. Durante o dia, trabalho em soluções de tecnologia. Nas minhas horas vagas, adoro mergulhar em histórias, seja lendo, escrevendo, jogando, RPG, o que for, eu provavelmente gosto. O Story Shack é a minha maneira de retribuir à comunidade global de contadores de histórias. É uma enorme saída criativa onde adoro dar vida às minhas ideias. Obrigado por visitar e, se você gostou desta ferramenta, não deixe de conferir algumas outras!
