❗️ Using tools to make ur commits more professional

README.md

Intro

Mesmo com o passar do tempo, um profissional precisa continuamente demonstrar suas skills de profissionalismo e maturidade. Quanto se trata de um profissional da área de TI introduzido em um contexto de desenvolvimento de software, isso também não é diferente. Programadores sêniors devem ser capazes de incentivar o uso de boas práticas para construção do seu software, como:

• Utilização de um sistema de versionamento e controle de código.
• Testes unitários e de integração.
• Cultura DevOps.
• Implementação de um metodologias de CI/CD.

E por ai vai... Atualmente é essencial a existência de um software capaz de manter o versionamento das suas entregas e controle do que está sendo modificado em seu software. Uma das soluções mais utilizadas é o Git.

De forma bem simples e chula, o Git nada mais é que um sistema de controle de versões distribuído.

Problem

A partir do momento em que você está utilizando o Git como forma de manter o controle de suas entregas, você está em um caminho fantástico. Porém, com o passar do tempo você percebe que precisa evoluir mais e busca forma de padronizar outros contextos.

É nesse momento que você precisa ser capaz de demonstrar profissionalismo e maturidade em seus repositórios obedecendo boas práticas na construção de mensagens de commit.

Um repositório de gerenciamento de versão é como um histórico organizado das mudanças realizadas.

Description

Escrever boas mensagens de commit pode ser um processo que irá levar tempo e exige prática. Todo commit realizado é considerado como uma foto, um snapshot, do seu trabalho. Se o seu código (mudança) é a sua foto, o seu commit é a legenda da sua foto. Nesse momento, o desenvolvedor tem total liberdade para descrever o que ele realizou em seu trabalho, onde cada um pode descrever da forma como preferir, o que foi realizado. Isso pode levar à diversos problemas...

Sem uma padronização na estrutura das mensagens e uma falta de regras básicas de escrita, todos os desenvolvedores presentes no projeto estão sujeitos a criar um repositório que não passa de um depósito de código, não tirando proveito dos recursos que uma ferramenta de gerenciamento de versão oferece.

O artigo “How to Write a Git Commit Message” é um daqueles textos para se deixar no favoritos e revisitá-lo de tempos em tempos. Apesar de não haver um único padrão a ser seguido, podemos extrair algumas regras úteis:

• Escreva o título de assunto de forma imperativa
• Limite a quantidade de caracteres da linha do assunto
• Não termine a linha de assunto com pontuação de período
• Use o corpo da mensagem para explicar o Porquê ao invés de Como.
• Limite a quantidade de caracteres para o corpo da mensagem e faça a quebra automática
• Separe com uma linha em branco o título com o assunto do corpo da mensagem

Seguir regras como essas pode se tornar um processo doloroso. Para isso, podemos utilizar algumas ferramentas:

• Commitlint.
• Husky.
• Commitizen.

Todas elas são desenvolvidos utilizando JavaScript, mas apesar disso, pode ser utilizada em um repositório que armazena qualquer tipo de informação.

Commit Lint

O commitlint é uma ferramenta que através do seu conjunto de regras, vai lhe ajudar a manter as mensagens dentro de alguma conversão, fazendo a validação das mensagens e indicando os erros quando alguma regra for violada.

Husky

O husky é uma ferramenta capaz de adicionar scripts (hooks) disparados antes (pre-commit) ou após (post-commit) seu commit. É responsável por executar o commitlint antes que seu código seja commitado e assim evitar que uma mensagem mal construída seja enviada ao repositório.

Commitizen

O commitizen é uma ferramenta responsável por guiar o desenvolvedor durante a escrita de uma mensagem padronizada. Uma sequeência de opções será exibida para que seja preenchida qualquer campo obrigatório durante o commit.

Pre-requisitos

Como já dito acima, utilizaremos as ferramentas Commitlint, Husky e Commitizen. Todas elas possuem como pré requisito o NodeJS e se integram com o gerenciamento de versão Git.

• NodeJS.
• Git.
• Yarn (Opcional).

Configurando um repositório

O procedimento de configuração do repositório deve ser realizado uma única vez e antes do início do desenvolvimento pelo time. Após realizado, todos os desenvolvedores só precisarão instalar as dependências antes do seu trabalho e seguir todo o processo que elas impõem.

Depois de instalado o NodeJS, precisamos instalar as outras ferramentas dentro de um repositório Git já inicializado. Para se utilizar as ferramentas Commitlint, Husky e Commitizen na padronização de suas mensagens, é necessário configurar o repositório. Se você utiliza um repositório remoto de gerenciamento de versão como GitHub ou GitLab, pode criar o repositório remotamente e realizar o clone para seu computador, caso prefira iniciar com um repositório local execute os comandos abaixo:

mkdir <nome-do-repositorio>
cd <nome-do-repositorio>
git init

Vamos alterar o arquivo .gitignore para ignorar a pasta node_modules, que é onde as ferramentas serão instaladas.

echo “node_modules/” >> .gitignore

Antes de instalarmos todas as dependências, vamos criar um arquivo package.json que é responsável por armazenar as informações, configurações e dependências de tudo que iremos utilizar.

npm init -y

Terminado esse procedimento podemos iniciar com a instação do Commitlint, que é responsável por verificar se a sua mensagem de commit está dentro de um determinado padrão.

npm install @commitlint/cli --save-dev

Em seguida instalamos o config-conventional, que é um conjunto de regras para as mensagens de commit.

npm install @commitlint/config-conventional --save-dev

Nesse momento precisamos informar para o Commitlint que ele deve utilizar as regras de validação presentes no config-conventional. Podemos fazer isso de diversas formas, porém utilizaremos a forma na qual criamos o arquivo commitlint.config.js na raiz do projeto.

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

Feito isso podemos instalar o Husky, ferramenta responsável por receber determinados eventos do Git e chamar o Commitlint para validar a mensagem de commit que você acabou de digitar.

Agora precisamos configurar para quais eventos o Husky deverá atuar. Para isso adicione a seguinte seção ao seu arquivo package.json.

"husky": {
   "hooks": {
        "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
        "prepare-commit-msg": "exec < /dev/tty && git cz --hook || true"
        }
  },

De acordo com a documentação do Git, durante o evento “commit-msg” é possível formatar e/ou validar a mensagem de “commit”. Já o evento “prepare-commit-msg” nos permite executar algo antes do editor da mensagem de commit ser chamado. E é justamente nesse ponto que o Commitizen vai trabalhar, guiando o usuário na elaboração dessa mensagem. Para instalar o Commitizen digite o seguinte comando:

npm install commitizen --save-dev

Temos também que configurá-lo para trabalhar com as regras de validação presente no config-conventional, executando o seguinte comando:

./node_modules/.bin/commitizen init cz-conventional-changelog --save-dev --save-exact

Pronto, neste momento podemos testar se as configurações foram realizadas com sucesso.

Observação: Uma outra boa prática é não misturar em um único commit diversos tipos de mudança, de forma que os commits sejam atômicos e não deixem o repositório em estado de falha.

Conclusion

As mensagens de “commit” são de suma importância para descrever o histórico de mudanças em um repositório. Encontrar uma forma adequada de escrevê-las não é uma tarefa fácil. O uso de técnicas como escrever o título de forma imperativa e o corpo do texto descrevendo o porquê da mudança no código nos ajuda a criar mensagens mais claras.

Padronizar as mensagens de “commit” do seu repositório demonstra maturidade e profissionalismo além de aumentar a confiabilidade na análise dos históricos de mudanças do software, auxiliando a reverter alterações e rastrear a causa raiz de defeitos.

O uso de ferramentas de automação como Commitlint, Commitizen e Husky garante que os padrões definidos não sejam quebrados e auxiliam os desenvolvedores na escrita de suas mensagens.

O que vem a seguir

Além dos benefícios já citados, a padronização das mensagens de “commit” é pré-requisito para automatizar o versionamento semântico, uma etapa importante da gerência de configuração de software. Isso é possível com o uso de ferramentas como semantic release capaz de fazer o tagueamento e geração de changelogs de forma automática.