Sério, eu DUVIDO que você nunca fez um commit assim:

git commit -m "force pipeline"

ou então:

git commit -m "dessa vez vai funcionar"

E as vezes eles até são necessários HAHAHA ou mais rápidos para enviarmos nossa simples alteração ou então forçar uma pipeline por completo.

Alguns dos problemas dessa prática é que acabamos sujando o histórico de commits e por consequência acaba dificultando o CodeReview, manutenção de código e limita extrair métricas das changes.

Agora que sabemos o que não fazer com nossos commits, vamos ao assunto real. Você conhece a Conventional Commits? Ela é uma especificação para tornar nossos commits mais legíveis de acordo com algumas convenções que vamos ver.

Padrões de commit

De início eles sugerem que nossos commits sejam da seguinte forma:

<tipo>: descrição
ou
<tipo>(escopo opcional): descrição

Misericórdia! O que é esse tipo!?

Tipos são palavras reservadas para qual tipo de alteração você está subindo!
Exemplo:

• fix: Nesse caso, estamos subindo uma correção de algum BUG existente na nossa aplicação. (Temos relação direta com o PATCH no versionamento semântico)
• feat: Estamos subindo uma nova Feature para nosso sistema! (Temos relação direta com o MINOR no versionamento semântico)
• docs: Commits que estão alterando alguma Documentação do nosso projeto.
• test: Commits que estão alterando a camada de Testes da aplicação.
• build: Commits que estão realizando modificações nos arquivos de Build e dependências do projeto.
• perf: Commits que não alteram a feature mas melhoram sua performance.
• style: Commits que apenas mexem na formatação de código ou removem algum código não utilizado.
• refactor: Commits que apenas refatoram o código, não alterando a funcionalidade.
• ci: Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

Olha quanta coisa que a gente pode fazer!

E o que é o escopo e descrição?

Basicamente, escopo é a palavra-chave do nosso commit e é opcional. Por exemplo, se eu estou corrigindo a funcionalidade de cadastro de usuários, faço da seguinte forma:

fix(users): Fix permission to create a user

Também temos Corpo e Rodapés!

• Corpo do commit: priorize a descrição mais detalhada do seu commit.
• Rodapé: geralmente preenchemos com número do Card do Kanban ou informações mais secundárias.

Agora vem a real parte boa! eu juro

Como quase tudo nessa vida pode ser automatizado, nós temos o plugin Commitizen, que basicamente é utilizado via Prompt e é um Helper para as especificações do Conventional Commits, com o qual você ainda pode criar suas próprias regras!

Muito legal esse assunto de Commits né!

Espero ter ajudado com este post e até a próxima!