Essa é uma revisão anterior do documento!
# Nomenclatura dos Commits
Adotamos o padrão Conventional Commits para nomear os commits de nossos projetos.
Objetivos
- Automatizar o versionamento de nossos projetos
- Automatizar a geração do Changelog
- Tornar o histórico de commits mais legível
- Padronizar a comunicação entre a equipe
Automação do versionamento
É importante que usemos esse padrão pois o Job de Versionamento das Pipelines de CI/CD lê os nomes dos commits, e com base neles, gera automaticamente a próxima versão, usando o padrão de Versionamento Semântico
Como funciona?
- Digamos que você recebeu a tarefa de implementar um feature em seu projeto.
- Você implementa, testa o feature em sua máquina, e agora está pronto para commitar.
- Como sua alteração é um feature, seu commit se chama:
feat(login): implementa "remember me" na página de login #39074, e faz push para o repositório. - No Gitlab, o Job de Versionamento lê o seu commit. Ele entende que é um
feat, e cria uma tag no seu commit. Digamos que a versão anterior era1.12.2, agora a versão é1.13.0. - Após isso, o Job de Versionamento também é gerado um changelog com as alterações.
Sintaxe dos Commits
Esta é a sintaxe dos commits que o Job de Versionamento está configurado para entender
<tipo>(<escopo opcional>): <descrição> [#<task redmine>]
<tipo>: Obrigatório. Refere-se ao tipo da alteração: se ele corrige um bug é umfix, se adiciona um feature, é umfeat. Veja: Quais Tipos de Commits existem?<escopo opcional>: Opcional. Descreve qual módulo do sistema foi alterado<descrição>: Descrição do o que o seu commit faz. Inicie sempre com verbos no presente do indicativo, ex.:corrige,altera,implementa,refatora,adiciona.
Quais Tipos de Commits existem?
Para o campo <tipo>, há as seguintes opções:
| Tipo | Descrição | Versão | Roda a pipeline? |
|---|---|---|---|
| build | Mudanças que afetam o sistema de build (Dockerfile) ou dependências externas (requirements.txt) | Não altera | Sim |
| ci | Alterações na pipeline de CI/CD | Não altera | Sim |
| docs | Alterações na Documentação | Não altera | Não |
| feat | Um feature novo (alterações que adicionam funcionalidade) | Aumenta a Minor | Sim |
| fix | Uma correção de bug (alteração que corrige funcionalidade) | Aumenta o Patch | Sim |
| perf | Uma mudança no código que melhora a performance | Aumenta a Minor | Sim |
| refactor | Uma mudança de código que nem corrige bugs, nem adiciona features. Apenas Refatoração. | Não altera | Sim |
| test | Adição de novos testes ou correção de testes existentes | Não altera | Sim |
Dica: Commits que começamdocs:não disparam a pipeline. Caso não queria disparar a pipeline, pode usá-lo.
Exemplos
Veja como exemplo um histórico de commits de um projeto fictício para entender como que
| Versão Atual | Nome do Commit | Nova Versão | Tipo de Alteração |
|---|---|---|---|
| 1.2.4 | fix: Corrige a formatação do parser markdown | 1.2.5 | Altera a versão de Patch |
| 1.2.5 | feat: Adiciona comando de pull para baixar novas páginas | 1.3.0 | Altera a versão Minor |
| 1.3.0 | docs(comandos): Cria sessão explicando como usar o comando de pull | 1.3.0 | Versão se mantem igual |
Dica: Iniciar descrição do commit com o presente do indicativo
Por convenção, inicie a Descrição do commit com verbos no presente do indicativo. A descrição deve indicar o que o commit faz. Exemplos:
- fix: corrige a formatação do parser markdown
- feat: adiciona comando de pull para baixar novas páginas
A intenção é facilitar a leitura do histórico de commits, e dos changelogs.
Mais informações
Para informações completas da sintaxe dos commits e versionamento semântico: Versionamento Semântico e guia de commits do Angular.