# Conventional Commits ![](https://miro.medium.com/v2/resize:fit:1037/1*gxEVzjhAt5Dh_rhx2WAN5w.png) 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](https://semver.org/lang/pt-BR/), 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: ```git <tipo>[escopo opcional]: <descrição> [corpo opcional] [rodapé(s) opcional(is)] ``` <!-- Essa identificação ocorre por meio de uma palavra que identifica se aquele commit realizado se trata de uma alteração de código, atualização de pacotes, documentação, alteração visul, teste: --> O commit contém os seguintes elementos estruturais, para comunicar a intenção ao utilizador da sua biblioteca: > [color=#c1036c] **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. --- > [color=#c1036c] **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. --- > [color=#c1036c] **Docs**: > Indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório. --- > [color=#c1036c] **Test**: > São utilizados quando são realizadas alterações em testes, seja criando, alterando ou escluindo testes unitários. --- > [color=#c1036c] **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). --- > [color=#c1036c] **Perf**: > Servem para identificar quaisquer alterações de código que estejam relacionadas a performance. --- > [color=#c1036c] **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. --- > [color=#c1036c] **Chore**: > Indicam atualizações de tarefas de build, configurações, pacotes... como por exemplo adicionar um pacote no gitignore. --- > [color=#c1036c] **CI**: > Indicam mudanças relacionadas a integração contínua (exemplo de escopos: Travis, Circle, BrowserStack, SauceLabs). --- > [color=#c1036c] **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. --- > [color=#c1036c] **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.