Skip to content

GitLab

Last edited by André Damé Fabião
Page history
This is an old version of this page. You can view the most recent version or browse the history.

processo

Home Escopo Processo Design/Mockups Configuração Arquitetura Gerência Código BD Qualidade Frontend Backend Analytics

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.

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/<id>_<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.
  • O merge deve ser feito com estratégia squash-commits.
  • Após o merge, a branch deve ser excluída (responsabilidade do Ages III).