Como é que normalmente faz commits de código…

Utilizo um formato de commits padronizado, frequentemente baseado em Conventional Commits. Isto garante uniformidade e automatiza alguns processos, como a geração do registo de alterações.

Formato típico de commit:

<tipo>[(área)]: <descrição>

[<corpo>]

[<nota>]

<tipo>: Obrigatório. Define o tipo de alterações (por exemplo, feat para novas funcionalidades, fix para correções, docs para alterações na documentação, style para formatação, refactor para refatoração, test para adição de testes, ci para alterações em CI/CD).
(área): Opcional. Indica a área da aplicação afetada pelas alterações (por exemplo, (componente: botão), (serviço: autenticação)).
<descrição>: Obrigatório. Descrição breve e precisa das alterações no modo imperativo (por exemplo, "adicionar botão", "corrigir erro de validação").
<corpo>: Opcional. Explicação mais detalhada das alterações, motivos e contexto. Separado por uma linha vazia da descrição.
<nota>: Opcional. Geralmente usado para indicar BREAKING CHANGE com descrição do motivo pelo qual quebra a compatibilidade, ou links para tarefas (por exemplo, Closes #123).

Exemplos:

feat: adicionar componente de janela modal

fix(validacao): corrigir erro de validação de email no formulário de registro

Agora o email é validado corretamente de acordo com a norma RFC 5322.

Closes #45

refactor(componente: botão): atualizar estilos e melhorar acessibilidade

Refatoração dos estilos do botão para cumprir o sistema de design.
Melhorada a acessibilidade adicionando atributos ARIA.

Isto ajuda a equipa a entender melhor a história das alterações, acelera a revisão do código e simplifica os processos automatizados.

Como é que normalmente faz commits de código?