03/11/2023
Padronização de commit com Commitlint
Conventional Commits na prática
O commit tem que seguir a seguinte estrutura:
<tipo>[escopo opcional]: <descrição> [corpo opcional] [rodapé(s) opcional(is)]
A mensagem deve ser escrita com letras minúsculas, com um espaço entre o dois pontos e a descrição e sem ponto final.
Geralmente eu escrevo apenas a primeira linha, vou colocar a lista com os tipos que podemos utilizar:
- chore: Atualização de tarefas que não ocasionam alteração no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas.
- feat: São adições de novas funcionalidades ou de quaisquer outras novas implantações ao código.
- fix: Essencialmente definem o tratamento de correções de bugs.
- refactor: Utilizado em quaisquer mudanças que sejam executados no código, porém não alterem a funcionalidade final da tarefa impactada.
- docs: Inclusão ou alteração somente de arquivos de documentação.
- perf: Uma alteração de código que melhora o desempenho.
- style: Alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.
- test: Adicionando testes ausentes ou corrigindo testes existentes nos processos de testes automatizados (TDD).
- build: Alterações que afetam o sistema de construção ou dependências externas (escopos de exemplo: gulp, broccoli, npm).
- ci: Mudanças em nossos arquivos e scripts de configuração de CI (exemplo de escopos: Travis, Circle, BrowserStack, SauceLabs).
- env: Utilizado na descrição de modificações ou adições em arquivos de configuração em processos e métodos de integração contínua (CI), como parâmetros em arquivos de configuração de containers.
Exemplos de Commits:
- chore: add commitlint e husky
- chore(eslint): obrigar o uso de aspas duplas no jsx
- refactor: refatorando a tipagem
- feat: add axios / buscando e tratando os dados
- feat(page/home): criando o roteamentento no next
Dessa maneira fica muito mais fácil a leitura do histórico de commits e o entendimento do que foi feito no código. Se você trabalha sozinho no projeto, experimente ficar 6 meses sem mexer no projeto. Com os commits padronizados, ao voltar a mexer nele, fica muito mais fácil lembrar quais foram suas últimas alterações.
OBS: eu já fiquei perdido no meu próprio código em projetos mais antigos e isso acontece porque ao longo do tempo evoluímos nosso código e adotamos novos hábitos de escrita, ao ponto de não reconhecermos nosso próprio código de meses atrás.
Acabei resumindo o Conventional Commits focando na parte que é mais utilizada, mas separei o link da convenção e de um artigo mais completo sobre o assunto, não deixe de ler:
By Vitor DevSP
link