Usando commit-lint para gerar releases com github-actions

Ter um padrão de commits é algo essencial para a saúde do projeto. Alguns dos principais pontos em adotar padrão de commits:

• Ao bater o olho na árvore de commits podemos identificar facilmente do que cada commit se refere (feature, bug, melhoria…).
• Deixa a árvore mais clean e organizada.
• Você pode usar os commits para gerar releases quase que automaticamente.
• Ajuda na hora de fazer um revert rs.

O padrão abaixo é utilizado em muitas empresas, como o Angular por exemplo.

Exemplo de padrão de commit: type(scope): subject

Primeiro definimos o tipo (feature, bug, melhoria…), segundo entre parênteses o escopo e por último a mensagem que explica melhor o que aquele commit faz.

Batendo o olho no exemplo abaixo, você consegue identificar que esse commit é para resolver um fix que veio do bug 20 e que ele atualiza a versão do Typescript para 3.0.

Ex:

fix(bug 20): update Typescript version to 3.0

Agora olha a diferença se usarmos apenas uma simples mensagem
Ex:

update Typescript version

Obviamente que dá para entender que está atualizando a versão do Typescript, mas falta algumas informações que a princípio achamos que não é importante, mas com o passar do tempo vamos percebendo a diferença que faz no dia a dia em questões de qualidade e organização.

Types

Abaixo estão alguns dos types que você pode utilizar enquanto estiver escrevendo o seu commit:

• build
• ci
• chore
• docs
• feat
• fix
• perf
• refactor
• revert
• style
• test

Dá para criar outros tipos, caso você queira 😃

Commit Lint

Para nos ajudar a manter os commits no padrão existe uma ferramenta chamada commitlint. Como o próprio nome diz é um lint que verifica se o commit está no padrão correto. Acaba que na correia do dia a dia a gente acaba ‘commitando’ mensagens que não faz sentindo nenhum né? rs.

Para começar é super simples.
Primeiro, instale as seguintes dependências em modo de desenvolvimento:

yarn add @commitlint/cli @commitlint/config-conventional -D

No exemplo de cima estou usando yarn, mas fique a vontade para usar NPM.

Segundo, crie um arquivo de configuração chamado commitlint.config.js na raíz do projeto com o seguinte conteúdo:

module.exports = { extends: [‘@commitlint/config-conventional’] }

Agora vamos precisar instalar o hooks e o husky que vão ser responsáveis para rodar o nosso script e verificar se o nosso commit está no padrão certinho.

yarn add hooks husky -D

Depois que instalar, a gente vai no nosso package.json e vamos adicionar as config deles:

“husky”: { “hooks”: { “commit-msg”: “commitlint -E HUSKY_GIT_PARAMS” }}

PRONTINHO!! Toda vez que alguém ‘commitar’o hooks vai verificar se o commit está no padrão definido no arquivo commitlint.config.js.

Por exemplo:

A primeira vez eu coloco o commit fora do padrão, pode-se perceber que ele aponta os erros e não aceita, na segunda vez eu ‘commitei’ da forma correta e ele passa sem nenhum problema.

Releases

Existe uma ferramenta chamada Semantic Releases que ajuda a gerar as releases de acordo com os commits. Por padrão ela usa as mensagens de convenção do Angular, mas você pode alterar. Para ler mais sobre sugiro dar uma lida na documentação.

É necessário configurar o Semantic Releases no CI do seu projeto, como o Github Actions ou similar. No exemplo abaixo usei o Github Actions

.github/workflows/main.yml

Se você for usar o Github Actions, será necessário configurar a chave GITHUB_TOKEN. Para ler mais sobre clique aqui.

Depois que tudo tiver configuradinho, olha que lindeza que fica 💛

https://github.com/laryssamagalhaes/commit-lint-and-releases-example/releases/tag/v1.0.0

Para ajudar na implementação criei um repositório de exemplo, assim vocês conseguem ver o passo a passo que eu fiz.

Links úteis

• Padrão de commits
• Commitlint
• Semantic Releases

Bom gente, é isso! Espero de verdade que esse post tenha sido útil! Vejo vocês em breve 💻 ❤️