Conventional Commits

A especificação do Conventional Commits é uma convenção simples para utilizar nas mensagens de commit. Ela define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas baseadas na especificação. Esta convenção se encaixa com o SemVer, descrevendo os recursos, correções e modificações que quebram a compatibilidade nas mensagens de commit.

A mensagem do commit deve ser estruturada da seguinte forma:

<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé(s) opcional(is)]

O commit contém os seguintes elementos estruturais, para comunicar a intenção ao utilizador da sua biblioteca:

Feat:
Indicam que seu trecho de código está incluindo um novo recurso seja de novas funcionalidades ou de quaisquer outras novas implantações ao código.

Obs: isso se correlaciona com MINOR do versionamento semântico.

---

Fix:
Indicam que seu trecho de código commitado está solucionando um problema (bug fix).

Obs: isso se correlaciona com PATCH do versionamento semântico.

---

Docs:
Indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório.

---

Test:
São utilizados quando são realizadas alterações em testes, seja criando, alterando ou escluindo testes unitários.

---

Build:
Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências (escopos de exemplo: gulp, broccoli, npm).

---

Perf:
Servem para identificar quaisquer alterações de código que estejam relacionadas a performance.

---

Style:
Indicam que houverem alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.

---

Chore:
Indicam atualizações de tarefas de build, configurações, pacotes… como por exemplo adicionar um pacote no gitignore.

---

CI:
Indicam mudanças relacionadas a integração contínua (exemplo de escopos: Travis, Circle, BrowserStack, SauceLabs).

---

Refactor:
Referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de perfomance devido a um code review.

---

Revert:
Reverte um commit anterior

A abordagem de Conventional Commits oferece uma maneira padronizada e estruturada de documentar mensagens de commit em sistemas de controle de versão, como o Git. Ela promove clareza, consistência e automatização no desenvolvimento de software.

Ao adotar esse padrão, as equipes podem obter diversos benefícios, como:

1. Melhor comunicação: As mensagens seguem um formato previsível, o que facilita a compreensão do histórico de mudanças por qualquer desenvolvedor, independentemente de sua familiaridade com o projeto.

2. Automação de processos: Conventional Commits integra-se bem a ferramentas de integração contínua e geradores de changelogs, permitindo a criação automática de versões e documentações de mudanças com base nos tipos de alterações realizadas (ex.: feat, fix, chore).

3. Facilidade na revisão de código: Mensagens claras ajudam a identificar rapidamente o escopo e o propósito de um commit.

4. Melhoria na gestão de versões semânticas: O padrão orienta práticas que podem ser usadas para definir automaticamente incrementos de versões (ex.: mudanças de major, minor ou patch), em alinhamento com o SemVer.

Por outro lado, a adoção inicial pode exigir esforços de aprendizado e adaptação, especialmente para equipes menos familiarizadas com o conceito. No entanto, os benefícios de longo prazo, como um desenvolvimento mais eficiente e colaborativo, justificam essa transição.

Concluindo, Conventional Commits é uma prática altamente recomendada para equipes que buscam padronização, automação e maior controle no ciclo de desenvolvimento de software.