Como nomear seus commits de forma simples

🚀 Doc simples para entender como, quando e por que utilizar os "Conventional Commits" em nossos commits de forma simples e simplificada

Índice

• Título e Imagem de capa
• Badges
• Índice
• Introdução
• Tipos mais comuns
• Deixando os commits mais "bonitos"
• Principais Regras de uso
• Como descrever um commit?
• Conclusão
• Referências

Introdução

Assim como eu, você já deve ter se perguntados várias vezes ❓ :
"Beleza, fiz tudo o que eu tinha que fazer ✅ , mas como eu vou nomear esse commit para que os outros entendam o que eu fiz?"

Para tentar responder, eu sempre pensei na base da pergunta: "PARA OS OUTROS" Isso significa que o principal papel de um commit bem descritivo é facilitar o papel da próxima pessoa no nosso projeto. 😄 Imagine receber uma nova task de continuidade ao processo criativo iniciado por outra pessoa e o último commit no repositório é:
"Fix some bugs" 😨

Não sei você, mas ia ficar perdidinho procurando no código o que foi corrigido ou não, com uma grande chance de deixar algo passar, simplesmente pelo motivo de não saber o que foi feito no commit!!

Então resolvi fazer essa pequena doc para aumentar a eficácia do entendimento dos nossos commits e evoluir nossa produtividade 🚀🚀🚀

Tipos mais comuns

No mundo dev temos várias formar de entitular e descrever nossos commits, dentre todas essas formas eu escolhi trazer de forma resumida os "Conventional Commits"

De forma resumida os "Conventional Commits" são simples prefixos para identificar os tipos de mudanças feitas no código. O objetivo de cada um desses prefixos é organizar o tipo de mudança feita naquele commit afim de ser útil para todos os devs que participam do projeto.

Tipos

• feat: Um commit que adiciona ou remove uma nova feature Exemplo: Uma função totalmente nova da aplicação ou sua remoção

• refactor: Uma refatoração feita no código que não vai alterar em nada a funcionabilidade ou qualquer tipo de lógica nas regras de negócio do projeto Exemplo: Alterar uma função "grande" para uma forma menos verbosa.

• style: Nesse caso podemos usar para duas situações: 1º - (Front-End) Alterações exclusivas na folha de estilo da aplicação Exemplo: Alterações no estilo da página, geralmente nos arquivos de estilos (CSS, SASS, LESS, Styled-Componentes...) 2º Mudanças na formatação do código que não alteram nenhuma regra de negócio Exemplo: Alterações nos formatadores, configurações nas convenções de lint, remover comentários, espaços em branco, etc...

• fix: A correção de algum problema/erro/bug no código Exemplo: Criar uma validação no uso de algum elemento da DOM para tratar o erro quando esse elemento não existir.

• chore: Mudanças na forma de compilar o projeto, adição de novos arquivos de configuração ou até mesmo ao adicionar novas bibliotecas. Exemplo: Adicionar um arquivo .gitignore.

• docs: Esse é simples (UFA), usado para indicar mudanças na documentação do projeto. Exemplo: Alteras essa linda DOC que você está lendo agora!! 💫

• build: Alterações no processo de BUILD ou nas dependências do projeto. Exemplo: Mudanças no GULP ou remover/adicionar dependencias no yarn.

• perf: Alterações específicas para melhorar a perfomace da aplicação. Exemplo: Trocar um map() por um forEach()

• revert: Destaca uma reversão diretamente relacionada ao commit anterior. Exemplo: Aqui não precisamos de exemplo (Assim espero ⚠️).

    git commit -m "feat: add buy together module"
    git commit -m "refactor: change way to loop for users"
    git commit -m "style: responsive styles for user card"
    git commit -m "fix: bug of duplicated users"
    git commit -m "chore: add .gitignore file"
    git commit -m "docs: add new commit patterns section"
    git commit -m "build: remove example.js dependency"
    git commit -m "perf: remove an unnecessary loop"
    git commit -m "revert: back to a862956 commit"

Exemplos dos tipos de commit citados anteriormente

Deixando os commits mais "bonitos"

Vamos deixar as coisas mais bonitas, organizadas e de fácil visualização:

Padrões de Emoji

Tipo do commit	Emoji	Palavra-chave
Adicionando uma dependência	➕ :heavy_plus_sign:	build
Alterações de revisão de código	👌 :ok_hand:	style
Animações e transições	💫 :dizzy:	style
Bugfix	🐛 :bug:	fix
Comentários	💡 :bulb:	docs
Commit inicial	🎉 :tada:	chore
Configuração	🔧 :wrench:	chore
Deploy	🚀 :rocket:	feat
Documentação	📚 :books:	docs
Em progresso	🚧 :construction:	feat
Mover/Renomear	🚚 :truck:	chore
Novo recurso	✨ :sparkles:	feat
Package.json em JS	📦 :package:	build
Performance	⚡ :zap:	perf
Refatoração	♻️ :recycle:	refactor
Removendo um arquivo	🔥 :fire:	chore
Removendo uma dependência	➖ :heavy_minus_sign:	build
Responsividade	📱 :iphone:	style
Estilização	💄 :lipstick:	style
Revertendo mudanças	💥 :boom:	fix
SEO	🔍️ :mag:	refactor
Tratamento de erros	🥅 :goal_net:	fix

Exemplos

Comando Git	Resultado no GitHub
git commit -m ":tada: Commit inicial"	🎉 Commit inicial
git commit -m ":books: docs: seção de como commitar"	📚 docs: Seção de como commitar
git commit -m ":bug: fix: Reatribuição de const"	🐛 fix: Reatribuição de const
git commit -m ":sparkles: feat: Módulo de compre junto"	✨ feat: Módulo de compre junto
git commit -m ":recycle: refactor: Passa para forEach()"	♻️ refactor: Passa para forEach()
git commit -m ":zap: perf: Altera o tamanho renderizado das imagens"	⚡ perf: Altera o tamanho renderizado das imagens
git commit -m ":lipstick: feat: Estilização CSS do formulário"	💄 feat: Estilização CSS do formulário
git commit -m ":bulb: docs: Comentários sobre a função addToCart( )"	💡 docs: Comentários sobre a função addToCart( )

Principais Regras de uso

• Só pode ser utilizado um type por commit
• O type é obrigatório em todo e qualquer commit

Como descrever um commit?

Depois de aprender e entender os casos de uso de cada tipo de commit você deve estar se perguntando:
"Hmm, mas eu sou péssimo em descrever o que eu fiz, foi tanta coisa que nem sei por onde começar"

E é exatamente por ler a sua mente que vou deixar algumas dicas aqui:

• Seja imperativo: Sempre pense que seu commit deve completar essa frase: "Esse commit irá {Descrição do commit aqui}
  Exemplo: Se você criou um módulo de compre junto completo, você pode pensar "Esse commit irá adicionar o módulo de compre junto" o resultado seria

  git commit -m "feat: add buy together module"
  

• Não crie um commit infinito: é comum abordar diversas tarefas em um único commit, afinal você já esta com a mão na massa 🔧, mas isso vai dificultar muito a organização dos commits e na descrição também, portanto, prefira commitar com mais frequência e particionar suas tarefas pensando nos tipos que mencionamos aqui, sem acumular vários tipos de commits em um só!

• Indeciso?: Se você ficou em dúvida sobre qual type deve usar no seu commit, muito provavelmente seu commit abordou muitas mudanças e está na hora de pensar em dividir esses commits hein!?

Conclusão

Legal né?
Achou difícil?

• Claro que não, facinho
• Muita informação 💀💀
• Mó fome

É claro que não é do dia pra noite que nossos commits ficam lindos e de fácil entendimento, mas tenho certeza de que essas dicas irão te ajudar a ser mais claro e objeto na hora de commitar e facilitar muito a comunicação na sua equipe!! ❤️

Referências

• https://medium.com/linkapi-solutions/conventional-commits-pattern-3778d1a1e657
• https://blog.rocketseat.com.br/como-fazer-um-commit-conventional-commits/
• https://github.com/iuricode/padroes-de-commits/blob/main/README.md
• https://www.alura.com.br/artigos/simplificando-controle-versao-conventional-commits
• https://www.conventionalcommits.org/pt-br/v1.0.0/