Skip to content

Instantly share code, notes, and snippets.

@ya-kimura
Last active August 28, 2024 15:25
Show Gist options
  • Save ya-kimura/7a50a25f98f3627345e84e7a0cb110b5 to your computer and use it in GitHub Desktop.
Save ya-kimura/7a50a25f98f3627345e84e7a0cb110b5 to your computer and use it in GitHub Desktop.
Boas Práticas - Conventional Commits

Breve resumo sobre o Conventional Commits

O conventional commits é uma metodologia com intuito de nos auxiliar a estruturar melhor as mensagens dos commits, e também manter o histórico de mudanças organizado e legível para as pessoas do time. Abaixo temos o exemplo da estrutura do commit seguindo o Conventional Commits.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

type: é o tipo do commit, ou seja, aqui a gente indica qual é o tipo da mudança.

scope: contexto da mudança, como: nova feature dentro do contexto frontend. O que é ótimo para repositórios monorepo onde há muitas alterações e também sinaliza se é front ou back por exemplo.

subject: é assunto do commit, e é sempre bom indicar a ação da mudança, exemplo: feat[módulo-front]: adiciona nova rota cadastrar usuário.

body: no corpo do commit podemos incluir mais informações a respeito das mudanças, incluindo links, informar version de algum pacote, etc…

footer: no rodapé é possível colocar infos adicionais como descrever breaking changes(implementações que não estão mais em uso), referenciar uma issue ao commit ou fechar a issue por meio do Close, e com isso, ao realizar o merge do commit na branch main, automaticamente, a mesma será fechada.

Obs: 
- o ideal é que a subject não ultrapasse de 50~72 caracteres. 
- não há limite de caracteres no body. 
- a opção de fechar a issue via commit, depende da disponibilidade de cada serviço dos repositórios remotos. E caso, seja utilizado alguma ferramenta de geração de changelog automático, o link da issue será associado ao commit. 
- se adicionar footer, o body se torna obrigatório.

O conventional possui algumas flags para sinalizar os tipos das mudanças, e são eles:

feat: sinaliza o desenvolvimento de uma nova feature, como: a criação de um novo serviço, funcionalidade, regra de negócio, etc…

test: sinaliza quando é criado cenários de testes, como: testes unitários ou integração.

refactor: sinaliza refatoração de código, como: alteração do código.

perf: sinaliza alterações que afetam a performance da aplicação, como: redução de ifs, melhorar query do banco, etc...

ci: sinaliza alterações de arquivos de configuração do CI/CD, como: Github actions, Gitlab-ci, Circle, Travis, etc…

docs: sinaliza mudanças na documentação do projeto, tipo README.md, swagger...Exemplo: documentação referente a deploy de ambiente, infos sobre dependências externas, etc…

revert: sinaliza reversão para um commit anterior.

style: sinaliza mudança de estilização de código, como: convenção de lint, indentação, espaço em brancos, remoção de comentários e consoles.log, mudanças de aspas duplas para simples, etc…

fix: sinaliza correções de erros/bugs.

chore: sinaliza mudanças que não afetam o código fonte da aplicação ou arquivos de testes, como: regras de lint, extensões de arquivo ao .gitignore, adição de dependências dev.

Referências:

Conventional Commits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment