Versionamento | Git

• Versionamento e quais tipos de comite gera as versões | Git

        {"type": "docs", "scope": "README", "release": "patch"},
        {"type": "refactor", "scope": "core-*", "release": "minor"},
        {"type": "refactor", "release": "patch"},
        {"scope": "no-release", "release": false}

Documentação

Convetional Commits

No contexto de versionamento de software, especialmente seguindo convenções como o SemVer (Versionamento Semântico) e convenções de commit como o Conventional Commits, os tipos de commit podem influenciar diretamente a alteração da versão do software. Aqui estão os tipos de commit mais comuns e como eles podem afetar a versão:

1. feat (Feature): Indica a adição de uma nova funcionalidade ao projeto. Segundo o SemVer, isso resulta em um aumento da versão menor (minor version), assumindo que o projeto segue o formato de versionamento MAJOR.MINOR.PATCH. Por exemplo, se a versão atual é 1.2.3, um commit do tipo feat levaria a versão para 1.3.0. ✨
2. fix (Fix): Usado quando é feita uma correção de bug. Isso resulta em um aumento da versão de correção (patch version). Seguindo o exemplo anterior, um commit do tipo fix mudaria a versão de 1.2.3 para 1.2.4. 🐛
3. BREAKING CHANGE: Um caso especial que pode ser incluído no footer de qualquer tipo de commit, mas é mais comumente associado com feat ou fix. Indica uma mudança significativa que quebra a compatibilidade com versões anteriores. Isso resulta em um aumento da versão maior (major version). Portanto, se a versão atual é 1.2.3, um commit com um BREAKING CHANGE levaria a versão para 2.0.0.

Os demais tipos de commit geralmente não afetam diretamente o versionamento semântico, a menos que sejam acompanhados de um BREAKING CHANGE. Incluem:

• docs (Documentation): Mudanças apenas na documentação. 📚
• style (Style): Alterações que não afetam o significado do código (espaços, formatação, ponto e vírgula ausentes, etc). 💎
• refactor (Refactor): Uma mudança no código que não corrige um bug nem adiciona uma feature. 📦
• perf (Performance): Uma alteração de código que melhora a performance. 🚀
• test (Test): Adição ou correção de testes. 🚨
• chore (Chores): Atualizações de tarefas e arquivos de configuração, não relacionadas a produção do código. ♻️
• build (Builds): Alterações que afetam a construção do sistema ou depedências externas. Ex: gulp, npm 🛠
• ci (CI): Alterações que afetam arquivos de CI ⚙️
• revert (Revert): Reverte para um commit anterior 🗑

Essa convenção ajuda a manter um histórico de commit claro e facilita a automatização do versionamento e a geração de changelogs.

Commit Type	Maps to	Title	Description	Emoji
initial	feat	Initial	Initial commit	🎉
dependencies	fix	Dependencies	Update dependencies	⏫
peerDependencies	fix	Peer dependencies	Update peer dependencies	⬆️
devDependencies	chore	Dev dependencies	Update development dependencies	🔼
metadata	fix	Metadata	Update metadata (package.json)	📦

Quando deve ter versionamento?

• Alteração/remoção de algum campo na request
• Inclusão de opções em enumeráveis
• Alteração de um determinado tipo
• Novos endpoints, parâmetros de query e novas propriedades em request que não acarretam em breaking change