Padronizando seus commits!

capa do post

Chega de fazer coisas como isso aqui :

Nesse post eu vou te mostrar como padronizar suas mensagens de commits para que qualquer dev consiga entender o que você fez ( e até mesmo você ).

Uma coisa que muitas pessoas não se preocupam ou não levam consideração em seus projetos são os textos dos commits, muitas vezes colocamos qualquer coisa como : "debugando o arquivo 1" e também não mantemos nenhuma constância ou seja comitamos quando lembramos desse "trabalho" :/

Mas... Os commits tem importância sim! Vamos a uma breve imaginação, você fez todo o seu projeto, da config ao deploy, porém só percebeu um erro quando foi para produção, e esse erro estava em uma versão passada que colocou tal coisa, e aí? O que vai fazer?

Ta aí a importância dos commits!

Com os commits você simplesmente consegue voltar exatamente para parte que deu errado como uma máquina do tempo sem alterar a linha atual. É um espetáculo mesmo!

O problema

Porém se os seus commits não tiverem um padrão nem você nem ninguém vai saber o momento de quando voltar, e também se não tiverem uma constância pode ser que o trecho que você precisa voltar não esteja registrado, então... Deu ruim denovo.

Vamos usar um padrão ?

Para fazer isso iremos seguir as regras do padrão Conventional Commits! ( Que inclusive já tem em seu site uma versão em português ) , para saber mais acesse aqui : Link

Nele você irá encontrar algumas regrinhas importantes, irei listar as principais que deve se atentar para seguir corretamente:

• Corpo do commit : tipo[ escopo ( opcional ) ]: descrição
• Letras minúsculas no início da descrição

Tipos dos commits:

• Fix : Usado quando o commit for feito para corrigir um problema no código
• Feat: Usado quando tem um novo recurso no código
• Build: Quando foi executado o build da nossa aplicação
• Chore: Quando foi adicionada uma nova dependência ou configuração
• Refactor: Quando for executada uma refatoração no código
• Docs: Usado quando ouver uma mudança na documentação do projeto
• Test: Quando foir executado um teste na aplicação

Existem alguns outros tipos mas esses são os principais :)

Aplicando no nosso projeto!

Para esse teste usarei o node.js como exemplo de aplicação mas ele pode ser usado em todas as outras tecnologias, porém a biblioteca de apoio que vou usar só está presente nas tecnologias JS.

O primeiro passo será instalar esa biblioteca, não é obrigatória mas, vai ajudar a não cometer certos vacilos na hora de comitar! rode o comando a seguir no seu gerenciador de pacotes preferido : yarn add git-commit-msg-linter -D ou npm install git-commit-msg-linter -D, essa lib vai bloquear todo commit que venha fora do padrão que escolhemos anteriormente, se estiver fora dele é barrado apontando também como corrigi-lo!

O segundo passo tem haver somente com a constância dos commits, caso sua modificação no código seja feita dentro dos tipos citados anteriormente, é hora de commitar, ou seja, caso seja uma correção de bug, uma nova feature, uma nova dependência, o build da aplicação, uma mudança na documentação, um teste ou uma refatoração está na hora de comitar!

Exemplo:

Espero que esse artigo tenha te ajudado a melhorar o padrão dos seus commits! Até a próxima! 😁