Padrões

Branches

O branch master deve ser considerado estável, mas somente as tags são versões liberadas para produção.

Todo desenvolvimento ou alterações devem ser feitos em forks e/ou em branches separados, nunca deve ser commitado diretamente no master. Para adicionar código de um branch para o master deve ser feito um pull/merge request. O pull/ merge request de uma alteração só poderá ser aberto quando o código for colocado em review.

O nome da branch deve ser o número do ticket associado as alterações com um prefixo do tipo de ticket. Segue os tipos de prefixos:

feat: Para tickets de feature
bug: Para branches de tickets de bugs
doc: Para tickets de documentação em geral
chore: Para tickets de atividades em geral
tech: Para tickets de débito técnico

Segue alguns exemplos de branches:

story-46666
feat-33556
bug-12334
doc-12312
tech-12314

As branches de fix seguem o segunte padrão:

fix-33556 (fix da feature)
fix-story-46666

Commits

O padrão de mensagem dos commits deve ser feat(produto/módulo) Mensagem.

feat(fwflex/openvpn) Adiciona ...
feat(fwflex/dbc) Altera ...

Antes de mergiar qualquer branch é necessário que a mesma tenha apenas um commit, para isso podemos seguir dois caminhos:

1- Realizar os commits conforme a necessidade e depois fazer o squash dos commits manualmente com o comando:

git rebase -i HEAD~13

Onde 13 seria o número de commits totais.

2- Ou efetuar o primeiro commit normalmente e depois utilizar o git amend e o push -f

git ammend
git push -f

Durante o review, deve-se verificar se existe apenas um commit na branch e se ele está dentro do padrão. Se não estiver, é necessário corrigi-lo.

Tipos de mensagem de commit

Os tipos podem ser um dos seguintes:

feat: Adição de novas funcionalidades ou melhorias
fix: Correção de um bug
doc: Adição ou atualização da documentação
refactor: Reorganizações de códigos e ajustes para melhorar a manutenção do código, não adiciona funcionalidades nem corrige bugs
chore: Mudanças nas ferramentas do repositório ou no processo de build

Commits de alteração de versão

As versões dos produtos seguem o versionamento semântico.

Commits de nova versão do produto devem alterar a somente a versão no arquivo VERSION e/ou no CHANGELOG.md, o comentário do commit deve ser no seguinte formato:

release: product-vMAJOR.MINOR.PATCH ...

onde:

MAJOR: alterações de versão onde há quebra de compatibilidade com as anteriores
MINOR: versões onde foram adicionadas novas funcionalidades ou melhorias
PATCH: versões onde foram corrigidos problemas, sem alterações de funcionalidade

Também deve ser criada uma tag no git no seguinte formato:

git tag product-MAJOR.MINOR.PATCH
git push orgin product-MAJOR.MINOR.PATCH

ex.:

# commit:
release: vpnflex-2.0.1

# tag:
vpnflex-2.0.1