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)
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 😁
Parabéns pelo artigo!!! Estamos usando essa semântica para o projeto da especificação Jakarta NoSQL e para o projeto Eclipse JNoSQL!!!