Padrões de Commits (Commit Patterns)

Os Padrões de Commits (Commit Patterns) são um conjunto de regras e convenções que guiam a forma como as mensagens de commit são escritas em sistemas de controle de versão, como o Git. O objetivo principal é tornar o histórico do projeto mais claro, organizado e fácil de entender para todos os membros da equipe e para o próprio desenvolvedor no futuro.

Os Padrões de Commits (Commit Patterns) são um conjunto de regras e convenções que guiam a forma como as mensagens de commit são escritas em sistemas de controle de versão, como o Git. O objetivo principal é tornar o histórico do projeto mais claro, organizado e fácil de entender para todos os membros da equipe e para o próprio desenvolvedor no futuro.

Por que usar Padrões de Commits?

• Transparência: Cada commit se torna uma pequena história, descrevendo de forma concisa o que foi alterado e por quê.

• Colaboração: Facilita a compreensão das mudanças por outros desenvolvedores, agilizando revisões de código e a integração de novas funcionalidades.

• Rastreabilidade: Permite localizar rapidamente alterações específicas, identificar bugs e entender a evolução do projeto.

• Automação: Ferramentas podem ser configuradas para gerar changelogs (listas de alterações) automaticamente, versionar o software (semantic versioning) e até mesmo disparar pipelines de CI/CD com base nos tipos de commit.

• Qualidade do Código: Incentiva commits menores e mais focados, o que geralmente leva a um código mais limpo e modular.

O Padrão Conventional Commits

O padrão mais popular e amplamente adotado é o Conventional Commits. Ele propõe uma estrutura clara e padronizada para as mensagens de commit, geralmente seguindo o formato:

<tipo>(<escopo opcional>): <descrição>

[corpo opcional]

[rodapé(s) opcional(is)]

Vamos detalhar cada parte:

1. Tipo (<tipo>) É o prefixo obrigatório que indica a natureza da mudança. Alguns dos tipos mais comuns incluem:

• feat: Uma nova funcionalidade. Ex: feat: adiciona tela de login

• fix: Uma correção de bug. Ex: fix: corrige erro de validação no formulário de cadastro

• docs: Alterações na documentação. Ex: docs: atualiza README com instruções de instalação


• style: Mudanças que não afetam o significado do código (formatação, espaçamento, etc.). Ex: style: formata código-fonte

• refactor: Uma refatoração de código que não adiciona uma funcionalidade nem corrige um bug. Ex: refactor: reestrutura componentes de autenticação

• test: Adição ou correção de testes. Ex: test: adiciona testes unitários para o serviço de usuário

• chore: Mudanças no processo de build ou ferramentas auxiliares (ex: configuração de dependências, scripts). Ex: chore: atualiza dependências do projeto

• perf: Uma mudança de código que melhora o desempenho. Ex: perf: otimiza query de busca de produtos

• build: Mudanças que afetam o sistema de build ou dependências externas (ex: npm, gulp). Ex: build: atualiza versão do webpack

• ci: Alterações nos arquivos de configuração de CI (Integração Contínua). Ex: ci: configura pipeline de deploy automático

• revert: Reverte um commit anterior. Ex: revert: reverte commit de alteração de layout

2. Escopo Opcional ((<escopo opcional>))

Fornece um contexto mais específico para a mudança. Geralmente indica a parte do projeto que foi afetada.

Ex: feat(login): adiciona funcionalidade de login (o escopo é login)

Ex: fix(api): corrige erro na rota de usuários (o escopo é api)

3. Descrição (<descrição>)

Uma breve e sucinta descrição da mudança, escrita no imperativo e no presente (como se você estivesse dando uma ordem). É recomendado que tenha no máximo 70 caracteres.

Ex: feat: adiciona botão de favoritos (e não "adicionei botão de favoritos" ou "adiciona um botão de favoritos").

4. Corpo Opcional ([corpo opcional])

Um parágrafo mais detalhado sobre a mudança, explicando o "porquê" e o "como". É útil para fornecer contexto adicional, justificativas ou detalhes técnicos.

5. Rodapé(s) Opcional(is) ([rodapé(s) opcional(is)])

Pode incluir informações como:

Quebras de compatibilidade (Breaking Changes): Usado para indicar mudanças que podem afetar o funcionamento de partes existentes do sistema ou de outros módulos. É comum usar BREAKING CHANGE: seguido de uma descrição.

Referências a issues ou tarefas: Links para tickets de gerenciamento de projetos (ex: Closes #123, Refs #456).

Exemplo de Commit Padronizado

feat(autenticacao): Implementa sistema de login com Google OAuth

Esta alteração adiciona o suporte para autenticação de usuários
usando a conta do Google OAuth. Os usuários agora podem se
registrar e fazer login através da plataforma do Google,
simplificando o processo de onboarding.

BREAKING CHANGE: O método `loginWithEmail` foi descontinuado
em favor da nova estrutura de autenticação.

Closes #42
Refs #18

Ferramentas para Auxiliar

• Existem ferramentas que podem ajudar a aplicar e validar os padrões de commit em seus projetos:

• Commitlint: Ajuda a validar as mensagens de commit no momento em que são criadas, garantindo que sigam as regras definidas.

• Commitizen: Fornece uma interface de linha de comando interativa para ajudar a construir mensagens de commit padronizadas, guiando o desenvolvedor através dos campos.

• Husky: Permite configurar "hooks" do Git, como pré-commit, para executar tarefas como a validação de commits antes que eles sejam efetivados no repositório.

A adoção de padrões de commits é uma prática que eleva a organização e a eficiência de qualquer projeto de desenvolvimento de software, especialmente em equipes. Começar a utilizá-los pode exigir um pequeno ajuste no fluxo de trabalho, mas os benefícios a longo prazo em clareza e manutenção do código são inegáveis.

Bonus: Emojis

Tipo de commit

Tipo de commit	Emojis
Commit inicial	🎉 :tada:
Tag de versão	🔖 :bookmark:
Novo recurso	✨ :sparkles:
Lista de ideias (tasks)	🔜 :soon:
Bugfix	🐛 :bug:
Documentação	📚 :books:
Testes	🧪 :test_tube:
Adicionando um teste	✅ :white_check_mark:
Teste de aprovação	✔️ :heavy_check_mark:
Acessibilidade	♿ :wheelchair:
Texto	📝 :pencil:
Package.json em JS	📦 :package:
Em progresso	🚧 :construction:
Arquivos de configuração	🔧 :wrench:
Removendo uma dependência	➖ :heavy_minus_sign:
Adicionando uma dependência	➕ :heavy_plus_sign:
Revertendo mudanças	💥 :boom:
Alterações de revisão de código	👌 :ok_hand:
Refatoração	♻️ :recycle:
Mover/Renomear	🚚 :truck:

Exemplos de utilização

git commit -m ":tada: Iniciando projeto"
git commit -m "heavy_plus_sign: build: Instalando dependencias"
git commit -m ":sparkles: feat (header): Adicionando e posicionando os icones" 
git commit -m "books: docs (readme): Criando documentação do projeto"

Com os 4 commits a cima teremos o seguinte histórico:

Referencia: conventionalcommits