|
|
# Board
|
|
|
|
|
|
# GitFlow
|
|
|
No projeto, seguimos o GitFlow conforme a imagem abaixo:
|
|
|
![image](uploads/f21fefd296746ac690ce21255eecbfae/image.png)
|
|
|
|
|
|
### Padrão de nomenclatura
|
|
|
Toda branch terá todo seu texto em minúsculo com palavras separadas por `-`.
|
|
|
A única seção é no id da US que podemos usar letras maiúsculas.
|
|
|
|
|
|
### main
|
|
|
Branch principal do projeto, apenas código testado e validado com o cliente pode ir para a main.
|
|
|
|
|
|
### feat/{id-us}-{nome-tarefa}
|
|
|
Feature branches são onde iremos desenvolver o código referente a uma **funcionalidade**.
|
|
|
|
|
|
Uma vez que o código tenha testes unitários e integração(backend), abrimos um Merge Request para a [develop](###develop)
|
|
|
|
|
|
Exemplos de nome são:
|
|
|
- feat/VDC-01-criar-tela-login
|
|
|
- feat/VDC-02-criar-endpoint-login
|
|
|
|
|
|
### develop
|
|
|
Branch de integração dos códigos desenvolvidos durante uma sprint. Todo MR de funcionalidades e correções é aberto para a develop e então, no final da sprint, um MR é aberto da develop para uma branch de release
|
|
|
|
|
|
### release/{numero-sprint}
|
|
|
Branches de release servem para agrupar o código desenvolvido até o code freezing de uma sprint e fazer o deploy na AWS.
|
|
|
|
|
|
Uma vez feito o deploy e validado com os clientes, abrimos um MR da release branch para main
|
|
|
|
|
|
Exemplos de nome são:
|
|
|
- release/1
|
|
|
- release/2
|
|
|
|
|
|
# Desenvolvendo uma US
|
|
|
## Escolhendo uma tarefa
|
... | ... | |