Automatizando padrões de mensagem de commit com @commitlint/cli

Primeiramente

Okay, vamos começar por entender o que é o git e porque deveríamos usá-lo.

Em termos planos, git é um Sistema de Controle de Versão Distribuído (SCV Distribuído), que torna mais fácil o rastreamento de mudanças em arquivos para que quando você mude um arquivo (criar/atualizar), ele pode determinar se o arquivo é novo e se não for o git te dirá exatamente o que mudou naquele arquivo. Há outros SVCs Distribuídos que você pode utilizar, tais como ArX, Fossil, Mercurial, Monotone e etc. É possível fazer um artigo inteiro apenas sobre SCVs (incluído os não distribuídos).

Mas então, sendo o git o SCV Distribuído mais popular, realmente faz sentido usá-lo? Sim, git tem uma ótima disposição de ferramentas remotas como gitlab, github e várias outras. Também é bem conhecido pelo versionamento de código e tem muito conhecimento livre na internet, então por razões práticas, git é a nossa melhor opção. Se você deseja conhecer mais sobre git, visite git-scm.

Neste artigo, focaremos na parte de commiting do git, que é basicamente um registro de uma mudança de arquivo ou de um grupo de arquivos. Há algumas convenções no momento de escrever uma mensagem de commit. Nós veremos sobre isso e alguns outros aspectos do git em si.

Inicializando

NOTA: Se você já conhece o git, você pode criar um diretório chamado git-commit-msg-patters, inicializar um repositório e pular direto para a seção Instalando Dependências.

Vamos criar um diretório que conterá nosso projeto, abra seu terminal e digite esses dois comandos em sequência:

mkdir git-commit-msg-patterns

cd git-commit-msg-patterns

O primeiro cria um diretório e o segundo acessa ele, todos os comandos daqui pra frente serão executados tendo esse diretório como base.

Em seguida, nós precisamos inicializar o repositório git com o comando git init, isso vai criar uma pasta .git no diretório atual e guardar as configurações do git e suas mudanças lá. Essa é a configuração básica.

Entendendo os conceitos básicos

Então, se você já entende o básico de git, você deve saber que agora nós temos um repositório e qualquer arquivo criado dentro dele estará com o status de untracked, quando um arquivo tem este status significa que o git não tem o arquivo indexado previamente em suas mudanças, em outras palavras, significa que o arquivo é novo dentro do repositório.

Quando você cria um arquivo, você deve usar o comando git add para mudar o status do arquivo para staged, um arquivo staged é basicamente o arquivo (ou grupo de arquivos) que serão associados com o próximo commit.

Como explicado anteriormente, um commit é basicamente um registro de mudanças em um arquivo ou grupo de arquivos, um repositório usualmente tem uma linha do tempo baseada em seus commits e o conceito de commit é usualmente explicado como "um ponto na linha do tempo do repositório", o que é uma explicação bastante direta.

Com tudo explicado, comecemos a parte principal.

Instalando Dependências

Nós usaremos os Git Hooks para checagem automática das mensagens de commit, especialmente o hook commit-msg que é o responsável por checar a mensagem de commit e validá-la. Eu farei um exemplo usando um template básico que eu aprendi neste artigo do dev.to, para tornar a checagem automática, nós usaremos algumas ferramentas JavaScript:

• @commitlint/cli
• husky

E uma dessas configurações:

• @commitlint/config-angular
• @commitlint/config-conventional
• @commitlint/config-lerna-scopes
• @commitlint/config-patternplate
• conventional-changelog-lint-config-atom
• conventional-changelog-lint-config-canonical
• commitlint-config-jira

Você também pode escrever sua própria configuração (independente de ser baseada em uma das acima ou uma configuração totalmente nova) e publicá-la no npm, eu escrevi uma para padronização de commits no meu trabalho e aqui está ela: @bristom/commitlint-config, você pode checar o Repositório do Github para ver quais são as regras.

Para instalar o husky, commitlint e o pacote de configurações que você escolheu como dependências de desenvolvimento você deve rodar:

npm install husky @commitlint/cli <config-package> --dev

Ou com yarn:

yarn add husky @commitlint/cli <config-package> --dev

No meu caso eu instalarei a @bristom/commitlint-config, já que é meu padrão.

Então, na raiz do nosso projeto, você pode criar dois arquivos: .huskyrc e commitlint.config.js. o arquivo .huskyrc guarda as configurações dos git hooks para o husky rodar e o arquivo commitlint.config.js guarda a configuração do commitlint para checar as mensagens de commit. O conteúdo de cada um está listado abaixo:

.huskyrc

{
    "hooks": {
        "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
}

commitlint.config.js

module.exports = {
    // Reescreva o @bristom/commitlint-config com o
    // nome do pacote de configuração que você instalou.
    extends: ['@bristom/commitlint-config']
};

Certo, com tudo configurado, vamos tentar fazer um commit:

git commit -m "anything"

Isso causará um erro em basicamente todas as configurações instaladas, já que não é compatível com nenhum padrão, mas se eu tentar:

git commit -m "[feat]: Initial commit"

Funcionará perfeitamente (cheque o padrão do seu pacote configuração para fazer o commit corretamente).

Olhar geral

Então, hoje nós aprendemos um pouco sobre git, git hooks e como automatizar a checagem de padrões de mensagens de commit usando algumas ferramentas Javascript.

Mas mesmo que eu tenha usado apenas Javascript, você pode implementar essas configurações em qualquer código seu e o melhor de tudo: usando as mesmas ferramentas, você só deve ter instalado o Node.js e ao invés de instalar o commitlint CLI para apenas um projeto, você o instala globalmente usando a flag -g do npm. A desvantagem é que você não terá os hooks automatizados, terá que os configurar por sua conta.

Obrigado por sua atenção e por ter vindo até aqui para aprender, espero te reencontrar logo!