Padronização e Clareza no Controle de Versão

O que é e para que serve

Conventional Commits é uma convenção para escrever mensagens de commit de forma estruturada e padronizada. Ele define um formato claro para facilitar a leitura, automação de processos e compreensão do histórico de mudanças em um projeto.

Essa convenção é especialmente útil em projetos com múltiplos colaboradores, pois melhora:

• A comunicação entre os membros da equipe;

• A geração automatizada de changelogs;

• A identificação de versões semânticas (SemVer);

• A integração com ferramentas de CI/CD (como GitHub Actions e Semantic Release).

A ideia central é prefixar as mensagens com tipos de alterações (como feat, fix, docs, etc.), seguidos de uma breve descrição.

Por exemplo:

feat: adicionar página de login

Iniciando o uso

Para adotar a convenção Conventional Commits no seu projeto, siga estes passos:

1. Familiarize-se com a estrutura padrão:

    <tipo>[!][(escopo)]: <descrição curta>
   

   Onde:

   • tipo: tipo da mudança (feat, fix, docs, etc.).

   • escopo (opcional): onde a mudança ocorreu (ex: login, api, header).

   • !: indica uma mudança que quebra compatibilidade (breaking change).

   • descrição curta: explicação clara e objetiva da mudança.

2. Tipos mais comuns:

   • feat: uma nova funcionalidade

   • fix: correção de bug

   • docs: mudanças na documentação

   • style: ajustes de formatação (espaços, ponto e vírgula, etc.)

   • refactor: refatorações sem alterar comportamento

   • test: adição ou ajuste de testes

   • chore: tarefas que não afetam o código de produção (ex: scripts, configs)

3. Ferramentas úteis:

   • commitlint: valida mensagens de commit.

   • husky: aplica hooks no Git para rodar o commitlint automaticamente.

   • semantic-release: gera changelogs e publica versões automaticamente com base nos commits.

Exemplos práticos

Aqui estão alguns exemplos de mensagens de commit seguindo a convenção:

feat(auth): adicionar autenticação via Google
fix(api): corrigir erro 500 ao buscar usuários inativos
docs(readme): atualizar instruções de instalação
style(header): remover espaço extra no CSS
refactor(user-service): otimizar função de login
test(profile): adicionar testes para edição de perfil
chore(ci): configurar pipeline do GitHub Actions

Breaking changes:

feat!: remover suporte à versão antiga da API

Ou, em uma mensagem de commit multi-linha:

refactor(core): remover função obsoleta de validação

BREAKING CHANGE: a função validateOldInput foi removida e substituída por validateInput.

Conclusão

Adotar a convenção Conventional Commits é um pequeno passo que traz grandes benefícios para o desenvolvimento de software. A padronização das mensagens melhora a colaboração, facilita automações e garante um histórico mais compreensível e útil.

Seja em projetos pessoais ou em grandes equipes, aplicar essa convenção contribui diretamente para a manutenibilidade, escalabilidade e profissionalismo do código.