Pular para o conteúdo principal

Introdução

Para a padronização de commits, utilizamos os padrões "Semantic Versioning" e "Conventional Commits", que segue algumas regras.

Número de versões - Semantic Versioning​

  • Major: Grandes alterações, como mudanças nas regras de negócios, funcionalidades importantes ou quebra de compatibilidade com versões anteriores
  • Minor: Alterações ou novas funcionalidades menores, que mantém compatibilidade com versões anteriores
  • Patch: Correções de erros

Mensagens de commits - Conventional Commits​

Estrutura​

Com os objetivos de melhorar a visibilidade de alterações e padronizar as mensagens de commits, utilizamos a seguinte estrutura:

    <tipo (Escrito em letras maiúsculas)>: Descrição das alterações

    Corpo com mais detalhes (opcional)

    Footer com notas úteis (opcional)

Tipos​

Os tipos que podemos utilizar são:

  • Build – Mudanças no sistema de build ou dependências externas (gulp, npm)
  • Chore – Mudança interna (Atualização ou adição de dependências, alteração em configurações de Linters, etc)
  • Docs – Mudanças em documentação, README, Changelog, etc.
  • Feat – Nova funcionalidade (feature)
  • Fix – Conserto de bugs e problemas
  • Perf – Mudança(s) para aumento de performance
  • Refactor – Mudança(s) de código que não conserta bugs nem adicionam nova funcionalidade.
  • Style – Mudança(s) que não afetam o significado do código (espaços em branco, formatação, etc.) ou estilos no front-end
  • Test – Adição ou correção de testes
  • BREAKING CHANGE – Mudança(s) maiores, que tiram a compatibilidade com versões anteriores.
Dica

É possível também utilizar emojis antes do tipo para expressar melhor a intenção do commit, como ✨ (:sparkles:) para FEAT, 🔨 (:hammer:) para FIX, entre outros.

Este detalhe é totalmente opcional.

Para ver todos os emojis possíveis, acesse o Repositório do Gitmoji

Exemplos​

✨ FEAT: Nova funcionalidade

FEAT: Novo método