|
|
|
## GitFlow
|
|
|
|
|
|
|
|
GitFlow é o processo de contribuição para os projetos utilizando a ferramenta de gerenciamento de versões Git.
|
|
|
|
As definições descritas serão utilizadas nos repositórios do **Frontend** e **Backend** do projeto, em conjunto com validações automáticas via **Husky** para garantir consistência nos nomes de branch.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Branches
|
|
|
|
|
|
|
|
#### Branches protegidas
|
|
|
|
|
|
|
|
Essas branches **não podem ser deletadas** e possuem regras rígidas de merge:
|
|
|
|
|
|
|
|
- **main** → representa o código em produção.
|
|
|
|
- Somente **AGES III e IV** podem aprovar merges para `main`.
|
|
|
|
- Só recebe código a partir de `development` ou de `fix`.
|
|
|
|
|
|
|
|
- **development** → branch base para o desenvolvimento.
|
|
|
|
- Todos os desenvolvedores criam branches a partir dela.
|
|
|
|
- Merge Requests são sempre revisados (mínimo 2 aprovações, uma delas de AGES III).
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
#### Branches não protegidas
|
|
|
|
|
|
|
|
São criadas a partir de `development` e seguem regras de nomenclatura validadas por hooks do git.
|
|
|
|
|
|
|
|
- **Feature**
|
|
|
|
- Padrão: `feature/<id>_<descricao>`
|
|
|
|
- Usada para implementar **novas funcionalidades**.
|
|
|
|
- Merge Request deve ser aberto **para development**.
|
|
|
|
|
|
|
|
- **Fix**
|
|
|
|
- Padrão: `fix/<descricao>` ou `fix/<descricao>`
|
|
|
|
- Usada para **correções de bugs**.
|
|
|
|
- Exemplo: `fix/erro-header` ou `fix/bug-formulario`
|
|
|
|
- Merge Request deve ser aberto **para main e development**.
|
|
|
|
|
|
|
|
⚠️ **Importante**: qualquer branch que não seguir esses padrões terá o push **bloqueado automaticamente** pelo Husky.
|
|
|
|
|
|
|
|
### Como criar uma branch
|
|
|
|
|
|
|
|
1. Sempre atualizar a branch `development` antes:
|
|
|
|
git pull origin development
|
|
|
|
|
|
|
|
2. Criar a nova branch:
|
|
|
|
git checkout -b feature/<nomeDaBranch>
|
|
|
|
|
|
|
|
3. Subir para o remoto:
|
|
|
|
git push --set-upstream origin feature/<nomeDaBranch>
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Commits
|
|
|
|
|
|
|
|
- Mensagens de commit devem ser **curtas, claras e em português**.
|
|
|
|
- Evite adicionar arquivos desnecessários.
|
|
|
|
- Exemplo de commit:
|
|
|
|
git add <arquivo>
|
|
|
|
git commit -m "ajuste na validação do formulário de login"
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Merge Request (MR)
|
|
|
|
|
|
|
|
Após finalizar a tarefa, deve-se abrir um MR seguindo o template:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Title**: descrição da tarefa ou correção (curta e direta).
|
|
|
|
**Description**:
|
|
|
|
|
|
|
|
## Link da Tarefa
|
|
|
|
[Inserir link da tarefa do Trello]
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
[Explique brevemente o que foi implementado ou corrigido]
|
|
|
|
|
|
|
|
## Checklist
|
|
|
|
- [ ] Não deixou string literais no código
|
|
|
|
- [ ] Utilizou variáveis padronizadas do design system
|
|
|
|
- [ ] Não deixou código comentado
|
|
|
|
|
|
|
|
## Screenshots (se aplicável)
|
|
|
|
[Adicione imagens se necessário]
|
|
|
|
|
|
|
|
- Selecione `Assign to me` no campo **Assignee**.
|
|
|
|
- Adicione **Labels** correspondentes.
|
|
|
|
- Todo MR precisa de **2 aprovações (uma obrigatória de AGES III)**.
|
|
|
|
- O merge deve ser feito com estratégia **squash-commits**.
|
|
|
|
- Após o merge, a branch deve ser excluída.
|
|
|
|
|
