Em qualquer projeto é essencial ter um histórico claro e compreensível das mudanças que acontecem ao longo do tempo. Uma das ferramentas que tornam isso possível é o sistema de controle de versão GIT, onde cada alteração é registrada através de um “commit”. O commit semântico é uma convenção que busca melhorar a clareza e a eficácia desses registros, deixar de forma objetiva cada mensagem registrada em cada commit feito dentro do projeto.
Vai facilitar não apenas a leitura e compreensão, mas também fornece informações úteis para ferramentas automatizadas que podem processar este formato padronizado.
Problemas com commits não-semânticos
Dificuldade em entender mudanças: Mensagens de commit vagas ou ambíguas como “Corrigido bug” ou “Atualizações” não fornecem contexto suficiente. Isso pode tornar difícil para desenvolvedores entender o racional ou impacto de uma mudança, especialmente em projetos maiores.
Falta de Padrão: Sem uma convenção definida, cada desenvolvedor tem sua própria maneira de escrever commits, levando a um histórico inconsistente e por vezes confuso.
Atraso na Identificação de Bugs: Sem entender claramente o propósito de cada commit, pode ser mais desafiador rastrear a origem de um bug ou comportamento inesperado no código.
Estrutura do commit semântico
O formato geral de um commit semântico é:
<tipo>(<escopo>): <mensagem>
- Tipo: Define a natureza da alteração, e.g., `feat`, `fix`, `docs`.
- Escopo: É opcional e contextualiza onde a mudança ocorre, e.g., `auth`, `backend`.
- Mensagem: Descreve a mudança de maneira concisa.
Tipos de Commit Semântico
- feat: Esta tag é usada quando uma nova funcionalidade ou recurso é adicionado ao projeto. Por exemplo: feat(search): implement search functionality
- fix: Usado quando um bug é corrigido. Por exemplo: fix(button): resolve issue where button doesn’t trigger
- docs: Alterações ou adições à documentação. Por exemplo: docs(readme): update installation instructions
- style: Refere-se a correções de estilo como formatação, falta de ponto e vírgula, etc., que não afetam a lógica do código. Exemplo: style(navbar): adjust padding for better alignment
- refactor: Mudanças no código que não introduzem novas funcionalidades nem corrigem bugs. Pode ser uma reestruturação ou uma otimização. Exemplo: refactor(login): use hooks instead of class components
- perf: Melhorias de performance no código. Exemplo: perf(images): reduce load time by compressing
- test: Quando se adicionam testes faltantes ou se corrigem testes existentes. Exemplo: test(cart): add unit test for item addition
- chore: Mudanças regulares ou de manutenção, como atualizações de dependências. Exemplo: chore(deps): update lodash to 4.17.20
** O escopo nem sempre é algo obrigatório porem pelo menos deve seguiro padrão com tipo: menasgem do commit
Exemplo de um commit:
- git commit -m “feat: implementing login button in header“
Ou se gosta de seguir em português também sem problema:
- git commit -m “feat: implementando botão de login no header”
Mensagem de Commit
A mensagem de commit deve ser clara concisa e descrever efetivamente o que foi feito.
- Concisão é o segredo: Tente manter a mensagem curta, mas informativa. O ideal é que ela não exceda 40/50 caracteres.
- Evite linguagem redundante: Frases como “Adicionei…” ou “Eu mudei…” são desnecessárias. Em vez disso, vá direto ao ponto: fix: resolve login com email.
- Use o tempo presente: Isso mantém a consistência e a leitura fácil. Em vez de “adicionado” ou “corrigido”, use “adiciona” ou “corrige”.
E se você está começando agora a aprender Git & Github 100% gratuito passo a passo para dominar o Git & Github: Acessasr curso
