O conventional commits é uma metodologia com intuito de nos auxiliar a estruturar melhor as mensagens dos commits, e também manter o histórico de mudanças organizado e legível para as pessoas do time. Abaixo temos o exemplo da estrutura do commit seguindo o Conventional Commits.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]type: é o tipo do commit, ou seja, aqui a gente indica qual é o tipo da mudança.
scope: contexto da mudança, como: nova feature dentro do contexto frontend. O que é ótimo para repositórios monorepo onde há muitas alterações e também sinaliza se é front ou back por exemplo.
subject: é assunto do commit, e é sempre bom indicar a ação da mudança, exemplo: feat[módulo-front]: adiciona nova rota cadastrar usuário.
body: no corpo do commit podemos incluir mais informações a respeito das mudanças, incluindo links, informar version de algum pacote, etc…
footer: no rodapé é possível colocar infos adicionais como descrever breaking changes(implementações que não estão mais em uso), referenciar uma issue ao commit ou fechar a issue por meio do Close, e com isso, ao realizar o merge do commit na branch main, automaticamente, a mesma será fechada.
Obs:
- o ideal é que a subject não ultrapasse de 50~72 caracteres.
- não há limite de caracteres no body.
- a opção de fechar a issue via commit, depende da disponibilidade de cada serviço dos repositórios remotos. E caso, seja utilizado alguma ferramenta de geração de changelog automático, o link da issue será associado ao commit.
- se adicionar footer, o body se torna obrigatório.feat: sinaliza o desenvolvimento de uma nova feature, como: a criação de um novo serviço, funcionalidade, regra de negócio, etc…
test: sinaliza quando é criado cenários de testes, como: testes unitários ou integração.
refactor: sinaliza refatoração de código, como: alteração do código.
perf: sinaliza alterações que afetam a performance da aplicação, como: redução de ifs, melhorar query do banco, etc...
ci: sinaliza alterações de arquivos de configuração do CI/CD, como: Github actions, Gitlab-ci, Circle, Travis, etc…
docs: sinaliza mudanças na documentação do projeto, tipo README.md, swagger...Exemplo: documentação referente a deploy de ambiente, infos sobre dependências externas, etc…
revert: sinaliza reversão para um commit anterior.
style: sinaliza mudança de estilização de código, como: convenção de lint, indentação, espaço em brancos, remoção de comentários e consoles.log, mudanças de aspas duplas para simples, etc…
fix: sinaliza correções de erros/bugs.
chore: sinaliza mudanças que não afetam o código fonte da aplicação ou arquivos de testes, como: regras de lint, extensões de arquivo ao .gitignore, adição de dependências dev.
Referências: