DEV Community

Gustavo Rodrigues
Gustavo Rodrigues

Posted on

Commits semânticos: Melhore seus commits em 5 minutos!

#ParaTodosVerem: Imagem com histórico de Commmits mal padronizados, como: AAAAAAAA e 'Here Have Code'

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!

Top comments (2)

Collapse
 
eguadorodrigo profile image
Rodrigo

Que assunto maneiro, Gustavo!
Gostei muito do conteúdo e a forma leve de passar ele, as brincadeiras, então parabéns !
Muito bacana também a indicação do plugin ❤️

Ass: Novo seguidor 😁

Collapse
 
dearrudam profile image
Maximillian Arruda

Parabéns pelo artigo!!! Estamos usando essa semântica para o projeto da especificação Jakarta NoSQL e para o projeto Eclipse JNoSQL!!!