Padrões de commits 📜

De acordo com a documentação do Conventional Commits, commits semânticos são uma convenção simples para ser utilizada nas mensagens de commit. Essa convenção define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas.

Esses commits auxiliarão você e sua equipe a entenderem de forma facilitada quais alterações foram realizadas no trecho de código que foi commitado.

Essa identificação ocorre por meio de uma palavra e emoji que identifica se aquele commit realizado se trata de uma alteração de código, atualização de pacotes, documentação, alteração de visual, teste...

Índice 🧭

• Formato da mensagem
• Tipo e descrição
• Validando commits com o hook commit-msg
• Recomendações
• Complementos de commits
• Padrões de emojis
• Exemplos
• Principais comandos do Git
• Glossário
• Contribuição

Formato da mensagem 🧩

:emoji: tipo(escopo opcional): descrição

• :emoji: - Representa o commit visualmente (veja a tabela de emojis). É recomendado, mas o hook aceita a mensagem sem ele. Pode ser o código (:sparkles:) ou o próprio emoji (✨).
• tipo - Um dos tipos abaixo, como feat ou fix.
• (escopo) - Opcional. Indica a área afetada, como em feat(auth): ....
• ! - Opcional. Indica uma mudança que quebra a compatibilidade (breaking change), como em feat(api)!: ....
• descrição - Resumo curto do que foi feito.

Exemplo: :sparkles: feat(auth): adicionar página de login

Tipo e descrição 🦄

O commit semântico possui os elementos estruturais abaixo (tipos), que informam a intenção do seu commit ao utilizador(a) de seu código.

• feat - Commits do tipo feat indicam que seu trecho de código está incluindo um novo recurso (se relaciona com o MINOR do versionamento semântico).

• fix - Commits do tipo fix indicam que seu trecho de código commitado está solucionando um problema (bug fix), (se relaciona com o PATCH do versionamento semântico).

• docs - Commits do tipo docs indicam que houve mudanças na documentação, como por exemplo no Readme do seu repositório. (Não inclui alterações em código).

• test - Commits do tipo test são utilizados quando são realizadas alterações em testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código)

• build - Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências.

• perf - Commits do tipo perf servem para identificar quaisquer alterações de código que estejam relacionadas a performance.

• style - Commits do tipo style indicam que houve alterações referentes a formatações de código, semicolons, trailing spaces, lint... (Não inclui alterações em código).

• refactor - Commits do tipo refactor referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de performance devido a um code review.

• chore - Commits do tipo chore indicam atualizações de tarefas de build, configurações de administrador, pacotes... como por exemplo adicionar um pacote no gitignore. (Não inclui alterações em código)

• ci - Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

• raw - Commits do tipo raw indicam mudanças relacionadas a arquivos de configurações, dados, features, parâmetros.

• cleanup - Commits do tipo cleanup são utilizados para remover código comentado, trechos desnecessários ou qualquer outra forma de limpeza do código-fonte, visando aprimorar sua legibilidade e manutenibilidade.

• remove - Commits do tipo remove indicam a exclusão de arquivos, diretórios ou funcionalidades obsoletas ou não utilizadas, reduzindo o tamanho e a complexidade do projeto e mantendo-o mais organizado.

• init - Commits do tipo init indicam o commit inicial do projeto.

• revert - Commits do tipo revert indicam que um commit anterior foi revertido.

• security - Commits do tipo security indicam alterações relacionadas à segurança da aplicação, como correção de vulnerabilidades, falhas de autenticação ou autorização, exposição indevida de dados e hardening de configurações.

🔧 Validando commits com o hook commit-msg

O hook commit-msg.sh roda a cada git commit e bloqueia mensagens que não seguem o formato. Mensagens geradas pelo próprio Git (Merge ..., Revert "...", fixup! ...) passam sem validação.

Instalação automática ⚡

Requisitos: Git instalado e um terminal com Bash. No Windows, use o Git Bash, que já vem com o Git.

1. Baixe este repositório:

git clone https://github.com/iuricode/padroes-de-commits.git

2. Instale o hook no seu projeto, informando o caminho dele (sem informar, o script instala na pasta atual):

./padroes-de-commits/install.sh caminho/do/seu-projeto

O script copia o commit-msg.sh para a pasta de hooks do projeto (respeitando o core.hooksPath, se existir) e dá a permissão de execução. Se já existir um hook commit-msg diferente, ele é salvo como commit-msg.bak.

3. Teste o hook. Este commit deve ser bloqueado:

git commit --allow-empty -m "mensagem fora do padrão"

Já mensagens como :sparkles: feat: adicionar funcionalidade xyz ou fix: corrigir bug são aceitas.

Instalação manual 📋

Copie o arquivo para a pasta de hooks do seu projeto, renomeando-o para commit-msg (sem extensão), e dê a permissão de execução:

cp caminho/para/commit-msg.sh .git/hooks/commit-msg
chmod +x .git/hooks/commit-msg

Nota: Substitua caminho/para/commit-msg.sh pelo caminho real do arquivo. Se a pasta .git/hooks não existir, crie-a com mkdir -p .git/hooks.

Para todos os seus projetos 🌍

Para aplicar o hook em todos os repositórios da sua máquina, use uma pasta de hooks global:

mkdir -p ~/.git-hooks
cp commit-msg.sh ~/.git-hooks/commit-msg
chmod +x ~/.git-hooks/commit-msg
git config --global core.hooksPath ~/.git-hooks

Atenção: com o core.hooksPath global, o Git passa a ignorar os hooks da pasta .git/hooks de cada repositório.

Com o framework pre-commit 🔌

Se o seu projeto usa o pre-commit, este repositório já traz o arquivo .pre-commit-hooks.yaml. Adicione o hook ao .pre-commit-config.yaml do seu projeto:

repos:
  - repo: https://github.com/iuricode/padroes-de-commits
    rev: v1.0.0
    hooks:
      - id: padroes-de-commits

Depois, instale o hook do estágio commit-msg:

pre-commit install --hook-type commit-msg

Personalize o script (opcional) 🎨

Se necessário, abra o arquivo commit-msg instalado em um editor de texto e altere as variáveis TYPES (tipos aceitos) e CONVENTIONAL_COMMIT_REGEX (formato da mensagem) para atender às necessidades do seu projeto.

Outros scripts 🧰

• push.sh - Assistente interativo: você escolhe o tipo, digita a mensagem e ele cria o commit (git commit -a, dos arquivos já rastreados) no formato :emoji: tipo: mensagem.
• prepare-commit-msg.sh - Experimental: sugere a mensagem de commit com IA a partir do git diff --staged, usando o serviço ai-commit-hooks, que precisa estar rodando localmente.

Recomendações 🎉

• Adicione um tipo consistente com o título do conteúdo.
• Recomendamos que a primeira linha tenha no máximo 4 palavras.
• Para descrever com detalhes, usar a descrição do commit.
• Usar um emoji no início da mensagem de commit representando o commit.
• Os links precisam ser adicionados em sua forma mais autêntica, ou seja: sem encurtadores de link e links afiliados.

Complementos de commits 💻

• Rodapé: informação sobre o revisor e número do card no Trello ou Jira. Exemplo: Reviewed-by: Elisandro Mello Refs #133
• Corpo: descrições mais precisas do que está contido no commit, apresentando impactos e os motivos pelos quais foram empregadas as alterações no código, como também instruções essenciais para intervenções futuras. Exemplo: see the issue for details on typos fixed.
• Descrições: uma descrição sucinta da mudança. Exemplo: correct minor typos in code

Padrões de emojis 💈

Tipo do commit	Emoji	Palavra-chave
Acessibilidade	♿ :wheelchair:
Adicionando um teste	✅ :white_check_mark:	test
Atualizando a versão de um submódulo	⬆️ :arrow_up:
Retrocedendo a versão de um submódulo	⬇️ :arrow_down:
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:
Arquivo .gitignore	🙈 :see_no_evil:	chore
Bugfix	🐛 :bug:	fix
Comentários	💡 :bulb:	docs
Commit inicial	🎉 :tada:	init
Configuração	🔧 :wrench:	chore
Deploy	🚀 :rocket:
Documentação	📚 :books:	docs
Em progresso	🚧 :construction:
Estilização de interface	💄 :lipstick:	feat
Infraestrutura	🧱 :bricks:	ci
Lista de ideias (tasks)	🔜 :soon:
Mocks	🤡 :clown_face:	test
Mover/Renomear	🚚 :truck:	chore
Novo recurso	✨ :sparkles:	feat
Package.json em JS	📦 :package:	build
Performance	⚡ :zap:	perf
Refatoração	♻️ :recycle:	refactor
Limpeza de Código	🧹 :broom:	cleanup
Removendo um arquivo	🗑️ :wastebasket:	remove
Removendo uma dependência	➖ :heavy_minus_sign:	build
Responsividade	📱 :iphone:
Revertendo mudanças	💥 :boom:	fix
Segurança	🔒️ :lock:	security
SEO	🔍️ :mag:
Tag de versão	🔖 :bookmark:
Teste de aprovação	✔️ :heavy_check_mark:	test
Testes	🧪 :test_tube:	test
Texto	📝 :pencil:
Tipagem	🏷️ :label:
Tratamento de erros	🥅 :goal_net:
Dados	🗃️ :card_file_box:	raw

💻 Exemplos

Comando Git	Resultado no GitHub
git commit -m ":tada: init: Commit inicial"	🎉 init: Commit inicial
git commit -m ":books: docs: Atualização do README"	📚 docs: Atualização do README
git commit -m ":bug: fix: Loop infinito na linha 50"	🐛 fix: Loop infinito na linha 50
git commit -m ":sparkles: feat: Página de login"	✨ feat: Página de login
git commit -m ":bricks: ci: Modificação no Dockerfile"	🧱 ci: Modificação no Dockerfile
git commit -m ":recycle: refactor: Passando para arrow functions"	♻️ refactor: Passando para arrow functions
git commit -m ":zap: perf: Melhoria no tempo de resposta"	⚡ perf: Melhoria no tempo de resposta
git commit -m ":boom: fix: Revertendo mudanças ineficientes"	💥 fix: Revertendo mudanças ineficientes
git commit -m ":lipstick: feat: Estilização CSS do formulário"	💄 feat: Estilização CSS do formulário
git commit -m ":test_tube: test: Criando novo teste"	🧪 test: Criando novo teste
git commit -m ":bulb: docs: Comentários sobre a função LoremIpsum( )"	💡 docs: Comentários sobre a função LoremIpsum( )
git commit -m ":card_file_box: raw: RAW Data do ano aaaa"	🗃️ raw: RAW Data do ano aaaa
git commit -m ":broom: cleanup: Eliminando blocos de código comentados e variáveis não utilizadas na função de validação de formulário"	🧹 cleanup: Eliminando blocos de código comentados e variáveis não utilizadas na função de validação de formulário
git commit -m ":wastebasket: remove: Removendo arquivos não utilizados do projeto para manter a organização e atualização contínua"	🗑️ remove: Removendo arquivos não utilizados do projeto para manter a organização e atualização contínua
git commit -m ":lock: security: corrigir falha de acesso não autenticado no endpoint de usuários"	🔒 security: corrigir falha de acesso não autenticado no endpoint de usuários

Principais comandos do Git 📜

• git clone url-do-repositorio-no-github - Clona um repositório remoto existente no GitHub para o seu ambiente local.

• git init - Inicializa um novo repositório Git no diretório atual.

• git add . - Adiciona todos os arquivos e alterações no diretório atual para a área de stage (preparando-os para o commit).

• git commit -m "mensagem do commit" - Registra as alterações adicionadas na área de stage com uma mensagem descritiva sobre o que foi modificado.

• git branch -M main - Renomeia a branch atual (master) para main. O -M é usado para forçar a renomeação, movendo a branch se necessário.

• git remote add origin https://github.com/usuario/nome-do-repositorio.git - Adiciona um repositório remoto chamado origin ao repositório local. Use https://github.com/usuario para configurar o repositório remoto com HTTPS ou git@github.com:usuario para configurar com SSH.

• git push -u origin main - Envia os commits da branch main do repositório local para o repositório remoto origin e define main como a branch padrão para futuros push e pull. O -u (ou --set-upstream) configura a branch upstream para facilitar os próximos comandos git push e git pull e eliminar a necessidade de especificar a branch.

• git remote add origin git@github.com:usuario/projeto.git git branch -M main git push -u origin main - Quando você já tem um repositório local e quer conectá-lo a um repositório remoto no GitHub, adiciona o repositório remoto, renomeia a branch principal para main e envia os commits iniciais.

• git fetch - Busca todas as atualizações do repositório remoto sem integrá-las à branch atual. Isso atualiza as referências remotas.

• git pull origin main - Atualiza a branch local main com as mudanças do repositório remoto origin. Combina git fetch e git merge.

• git push --force-with-lease - Forma mais segura de forçar o envio de alterações locais para o repositório remoto. Verifica se não houve alterações feitas por outros colaboradores desde sua última atualização local, evitando sobrescrever acidentalmente o trabalho de outros.

• git revert id_do_commit_que_vai_ser_revertido - Cria um novo commit que desfaz as alterações feitas pelo commit especificado, preservando o histórico. Útil para desfazer mudanças de forma segura sem reescrever o histórico.

• git reset --hard id_do_commit_anterior_ao_que_vai_ser_apagado - Redefine o repositório para o estado do commit especificado, apagando todas as mudanças feitas após esse commit. Ideal para uso local. Para sincronizar remotamente, use git push --force-with-lease posteriormente.

• git commit --amend -m "mensagem_reescrita" - Altera a mensagem do último commit. Após usar este comando, sincronize remotamente com git push --force-with-lease.

• git cherry-pick HASH_DO_COMMIT - Utilizado para obter um commit específico. Exemplo de uso: Imagine que você tenha duas branchs (main) e (develop) e na segunda você tem 3 commits mas deseja apenas pegar o primeiro commit dela, com o uso de cherry-pick você pode.

• git switch <branch> - Alterna para uma branch diferente no repositório local. Use git switch -c <branch> para criar e alternar para uma nova branch.

Glossário 📖

• fork - Cópia de um repositório para a sua própria conta no GitHub. Isso cria um novo repositório em sua conta que é independente do original, permitindo que você faça alterações sem afetar o repositório original.

• issues - Ferramenta usada para gerenciar tarefas, pedidos de novos recursos e correções de bugs em projetos de código aberto. As issues devem ser descritas e listadas, permitindo aos colaboradores discutirem e rastrearem o progresso das mesmas.

• pull request - Mecanismo usado para submeter alterações propostas ao repositório original. Um pull request é uma solicitação para que os mantenedores do projeto revisem e potencialmente incorporem as alterações. O pull request passará por um processo de avaliação e pode ser aceito ou rejeitado.

• gist - Ferramenta que permite o compartilhamento de trechos de código sem a necessidade de criar um repositório completo. Gists podem ser compartilhados publicamente ou de forma privada.

Contribuição ✨

Ajude a comunidade tornando este projeto ainda mais incrível. Leia como contribuir clicando aqui e a licença. Estou convencido de que juntos alcançaremos coisas incríveis!