📌 Controle de Versionamento

🔀 Estratégia de Branches

Branches Principais

• main (protegida)

  • Representa o código em produção
  • ❗ Commits diretos são bloqueados
  • Atualizada apenas via merge de develop (deploys) ou hotfix/

• develop

  • Branch de integração para novas funcionalidades
  • Recebe merges das feature branches

Branches de Trabalho

• feature/JIRA-123-descricao

  • Padrão: feature/ + código do JIRA + descrição breve
  • Exemplo: feature/codjira-cadastro
  • Criada a partir da develop

• hotfix/JIRA-123

  • Para correções urgentes em produção
  • Criada a partir da main

🔁 Fluxo Resumido

Guia de Uso do Git Flow (Sem Ferramentas Adicionais)

Introdução

O Git Flow é um modelo de branching para Git que organiza o desenvolvimento do projeto de forma estruturada, garantindo estabilidade no código em produção e facilitando a colaboração entre desenvolvedores. Este guia descreve o fluxo de trabalho sem necessidade de instalação de ferramentas adicionais.

Estrutura de Branches

O Git Flow segue a seguinte estrutura principal:

• main: Contém o código estável e pronto para produção.
• develop: Contém o código em desenvolvimento. Todas as novas funcionalidades são integradas aqui antes de serem preparadas para produção.
• feature/nome-da-feature: Criada a partir de develop para desenvolver uma nova funcionalidade.
• release/x.y.z: Criada a partir de develop para preparar uma nova versão antes de ser integrada em main.
• hotfix/x.y.z: Criada a partir de main para corrigir problemas críticos em produção.

Papéis e Comandos

Desenvolvedores (Criando e Finalizando Features)

1. Criar uma nova branch de feature a partir de develop:

   git checkout develop
   git pull origin develop
   git checkout -b feature/nome-da-feature

2. Desenvolver a funcionalidade e realizar commits:

   git add .
   git commit -m "Implementa funcionalidade X"

3. Enviar a feature para o repositório remoto:

   git push origin feature/nome-da-feature

4. Criar um Pull Request (PR) para mesclar a feature em develop.

Revisores (Revisão e Merge para Develop)

1. Revisar o Pull Request e, se aprovado, fazer o merge da feature/nome-da-feature em develop.
2. Após o merge, deletar a branch da feature no repositório remoto:

   git branch -d feature/nome-da-feature
   git push origin --delete feature/nome-da-feature

Gestores de Release (Criando e Finalizando uma Release)

1. Criar uma branch de release a partir de develop:

   git checkout develop
   git pull origin develop
   git checkout -b release/x.y.z

2. Realizar os últimos ajustes e commits.
3. Criar um Pull Request para mesclar a release em main.
4. Após aprovação, fazer o merge para main e criar uma tag:

   git checkout main
   git merge --no-ff release/x.y.z
   git tag -a vX.Y.Z -m "Versão X.Y.Z"
   git push origin main --tags

5. Mesclar a release de volta para develop:

   git checkout develop
   git merge --no-ff main
   git push origin develop

6. Excluir a branch de release:

   git branch -d release/x.y.z
   git push origin --delete release/x.y.z

Correções Críticas (Hotfixes)

1. Criar uma branch de hotfix a partir de main:

   git checkout main
   git pull origin main
   git checkout -b hotfix/x.y.z

2. Implementar a correção e commitar:

   git add .
   git commit -m "Corrige problema crítico X"

3. Criar um Pull Request para merge em main.
4. Após o merge, criar uma tag e enviar:

   git tag -a vX.Y.Z-hotfix -m "Hotfix X.Y.Z"
   git push origin main --tags

5. Mesclar o hotfix em develop:

   git checkout develop
   git merge --no-ff main
   git push origin develop

6. Excluir a branch de hotfix:

   git branch -d hotfix/x.y.z
   git push origin --delete hotfix/x.y.z

Considerações Finais

• Sempre crie branches de feature a partir de develop.
• Releases devem ser testadas antes de serem finalizadas.
• Hotfixes devem ser feitos apenas para problemas críticos.
• Todos os Pull Requests devem ser revisados antes de merge.

Dúvidas? Entre em contato com o time técnico! ✉️