GitLab

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/

3. Subir para o remoto: git push --set-upstream origin feature/

Commits

• Mensagens de commit devem ser curtas, claras e em português.
• Evite adicionar arquivos desnecessários.
• Exemplo de commit: git add 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.