Modelos de mensagens de commit do Git

Visão geral da categoria de modelo

Mensagens de commit consistentes tornam o histórico de um repositório legível, habilitam changelogs automatizados e tornam a revisão de código mais rápida - mas digitar manualmente um commit convencional devidamente estruturado é tedioso o suficiente para que a maioria dos desenvolvedores recorra a resumos de uma linha. Um expansor de texto resolve isso transformando um gatilho curto em um scaffold de commit completo com tipo, escopo, resumo, corpo e rodapé já definidos, para que você preencha os detalhes em vez de lembrar o formato. Como o Lightning Assist funciona em todo o sistema — inclusive no terminal, onde a maioria dos commits realmente acontece, e na caixa de commit do VS Code — os mesmos modelos funcionam se você fizer commit a partir da linha de comando, do seu IDE ou de uma GUI do Git. A voz push-to-talk pode até ditar o parágrafo mais longo do corpo quando suas mãos estão fora do teclado no meio da depuração.

Quando usar esses modelos

Use modelos de mensagem de commit em cada commit, mas eles compensam mais nos commits que importam mais tarde: correções de bugs que você revisitará, alterações importantes que afetam outras equipes e qualquer commit em um repositório que gera automaticamente releases ou changelogs a partir do histórico de commits. Se o seu projeto usa Commits Convencionais, liberação semântica ou qualquer automação de changelog, um andaime consistente não é apenas organização – é o que faz as ferramentas funcionarem. Mesmo em projetos solo, um log git legível escrito em um formato consistente economiza tempo real quando você divide uma regressão ao meio ou tenta lembrar por que uma alteração foi feita há seis meses.

Modelos de exemplo nesta categoria

• Andaime de commit convencional: tipo, escopo opcional, resumo, corpo e rodapé com referência de ticket.
• Corrigir commit com contexto de bug: o que quebrou, a correção e o problema que ele resolve.
• Confirmação de mudança significativa: a mudança mais um rodapé BREAKING CHANGE claramente marcado para ferramentas de lançamento.

Exemplos de modelos na prática

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

Como começar

Comece com o andaime geral do Conventional Commit em um gatilho curto como ;cc, com espaços reservados para tipo, escopo, resumo, corpo e ticket. Adicione uma variante ;fix pré-preenchida com o tipo de correção e um rodapé "Closes #", e uma variante ;ccbreak com o rodapé BREAKING CHANGE para os commits de quebra raros, mas importantes. Digite o gatilho em seu terminal ou na caixa de commit do seu editor e ele se expande inline conforme você digita - não é necessária nenhuma tecla de atalho e funciona da mesma forma em ambos porque a expansão abrange todo o sistema. Quando os andaimes parecerem naturais, adicione modelos de descrição de PR e resposta de revisão de código para que todo o fluxo de envio de alterações seja consistente.

Dicas profissionais

• Mantenha a linha de resumo com menos de 50 caracteres e no modo imperativo ("adicionar", não "adicionado") - a maioria das ferramentas e revisores git esperam esta convenção.
• Use um rodapé "Fecha #[problema]" nas confirmações de correção para que a mesclagem da alteração feche automaticamente o ticket vinculado em seu rastreador.
• Reserve o modelo de alteração significativa para alterações genuínas de contrato e sempre inclua a etapa de migração – uma nota de alteração sem ela apenas cria carga de suporte.
• Dite o corpo do commit com push-to-talk quando suas mãos estiverem fora do teclado no meio da depuração e, em seguida, use AI Enhance para restringir o texto.