O uso do Git para nós Devs é algo essencial, seja em projetos pessoais, de código aberto com muitas pessoas ou uma comunidade.
Dado isso, é importante utilizarmos o git commit apropriadamente. Termos uma linguagem coerente e padronizada ajuda a todos os envolvidos no projeto a entenderem as mudanças ocorridas.

Na imagem acima, percebemos o quão prejudicial podem ser commits mal comentados, uma vez que não conseguimos entender a natureza da mudança ocorrida e o contexto que se aplica. A longo prazo, o efeito é ainda mais danoso, dado que a manutenibilidade do software é prejudicada devido a incoerência no escopo dessas mudanças, e como afetaram o projeto no passado.
Diante disso, vamos falar um pouco sobre o Conventional Commits Pattern.

O que é ?

O Conventional Commits é uma convenção simples de mensagens de commit, que segue um conjunto de regras e que ajuda os projetos a terem um histórico de commit explícito e bem estruturado.

Como utilizar

As regras são muito simples, como demonstrado abaixo temos um tipo de commit (type), o escopo/contexto do commit (scope) e o assunto/mensagem do commit (subject).

!type(?scope): !subject
<?body>
<?footer>

Dessa maneira, ! indica os atributos obrigatórios e ? indica os atributos não obrigatórios.

Subject: Imperativo ao invés de pretérito (modo passado)

Desse modo nós estamos dizendo à nossa equipe o que fará o commit se aplicado.

“If applied, this commit will change the markup”, o que faz mais sentido do que: “If applied, this commit will changed the markup”

Type: Quais são os tipos de commit

O type é responsável por nos dizer qual o tipo de alteração ou iteração está sendo feita, das regras da convenção, temos os seguintes tipos:

• test: indica qualquer tipo de criação ou alteração de códigos de teste. 
  Exemplo: Criação de testes unitários.

• feat: indica o desenvolvimento de uma nova feature no projeto. 
  Exemplo: Acréscimo de um serviço, funcionalidade, etc.

• refactor: usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema. 
  Exemplo: Mudanças após um code review

• style: empregado quando há mudanças de formatação e estilo do código que não alteram o sistema de nenhuma forma.
  Exemplo: Mudar o style-guide, mudar de convenção lint, arrumar indentações, remover espaços em brancos, remover comentários, etc..

• fix: utilizado quando há correção de erros que estão gerando bugs no sistema.
  Exemplo: Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.

• chore: indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento.
  Exemplo: Mudar regras do eslint, adicionar prettier, adicionar mais extensões de arquivos ao .gitignore

• docs: usado quando há mudanças na documentação do projeto.
  Exemplo: adicionar informações na documentação da API, mudar o README, etc.

• build: utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas.
  Exemplo: adicionar/remover dependências do npm, etc...

• perf: indica uma alteração que melhorou a performance do sistema.
  Exemplo: alterar ForEach por while

• ci: utilizada para mudanças nos arquivos de configuração de CI.
  Exemplo: Circle, Travis, BrowserStack, etc.

• revert: indica a reversão de um commit anterior.

Observações:

• Só pode ser utilizado um type por commit;

• O type é obrigatório;

• Caso esteja indeciso sobre qual type usar, provavelmente trata-se de uma grande mudança e é possível separar esse commit em dois ou mais commits;

• A diferença entre build e chore pode ser um tanto quanto sutil e pode gerar confusão, por isso devemos ficar atentos quanto ao tipo correto. No caso do Node.js por exemplo, podemos pensar que quando há uma adição/alteração de certa dependência de desenvolvimento presente em devDependencies, utilizamos o chore. Já para alterações/adições de dependências comuns aos projeto, e que haja impacto direto e real sobre o sistema, utilizamos o build.

Scope: contextualizando o commit

Nesse ponto — e seguindo as convenções passadas — conseguimos entender o tipo de alteração que foi realizada no commit (commit type) e entender com clareza o que o commit irá trazer se aplicado (commit subject).

Mesmo o scope não sendo obrigatório, ele pode ser utilizado para contextualizar o commit e trazer menos responsabilidade para a subject, fazendo com que ele seja mais breve e conciso possível. Lembrando que o scope deve ser inserido no commit entre parênteses.

Observação: Os escopos devem ser separados com /

Conclusão

Escrevi este artigo no intuito de registrar um dos meus aprendizado meu (eram só umas notas no notion), mas espero que possa ajudar outros desenvolvedores por ai.