Fluxo de versionamento

Guia completo de práticas e processos para versionamento, commits e entrega contínua em projetos de desenvolvimento.

Estrutura de Branches

Branches Principais

Branch	Descrição	Recebe merges de
main	Produção. Código estável e pronto para deploy	desenv/* e hotfix/*
desenv	Integração diária. Base para todas as feature branches. Ponto central de desenvolvimento	feature/*
hotfix/	Correções críticas em produção. Criadas a partir da main para problemas urgentes	-

Convenção de nomes

(feat, fix, ref, hotfix)/CHAVE-DO-TICKET-descricao-curta

Exemplos:

• feat/ABC-123-adicionar-login
• fix/DEF-456-corrigir-botao-enviar
• hotfix/GHI-789-corrigir-crash-pagamento

---

Sistema de Versionamento

Características

• Baseado em Tickets: Cada versão incrementa conforme tickets resolvidos

  Versão inicial: 1.0.000
  +2 tickets ³ 1.0.002
  +3 tickets ³ 1.0.005

• Frequência Diária: Uma versão gerada por dia com todos os PRs aprovados do período

• Gerar em todas as plataformas: Cada versão gera builds para iOS, Android e APK, armazenados no Drive

---

Padrão de Commits

Formato Commitlint

<tipo>(<chave-ticket>): <descrição>

Exemplos práticos

feat(ABC-123): descrição do ticket
fix(DEF-456): corrigir bug no botão
chore(GHI-789): atualizar dependências
refactor(JKL-012): otimizar função de busca

Tipos comuns

Tipo	Descrição
feat	Nova funcionalidade
fix	Correção de bug
chore	Tarefas de manutenção
refactor	Refatoração de código
docs	Documentação

Regra importante

1 commit por ticket, porém caso seja necessário, múltiplos commits podem ser feitos, desde que mantenham a mesma chave do ticket.

---

Processo de Pull Requests

Fluxo obrigatório

1. Todo código desenvolvido passa por PR na branch desenv
2. PR deve ser revisado e aprovado antes do merge
3. PR diário aprovado gera nova versão
4. Na descrição do PR: Adicionar o link do Ticket

Responsáveis por aprovação

Projeto	Responsáveis
Force Web/App, Sales	Luis, Chico, Michel, Denis
Vidya Manager	Luis, Matheus
Rocket	Denis, Luis, Michel, Chico
Promoter	Michel, Chico
Express	Michel, Chico

---

Code Review: Responsabilidades

Checklist do revisor

1. Quem faz o merge é responsável por toda a revisão do código
2. Garantir que commits seguem o padrão estabelecido
3. Conferir possíveis conflitos e impactos em outras branches
4. Validar boas práticas e qualidade geral do código
5. Integração do GitHub Copilot para auxiliar no processo de revisão automatizada

---

Fluxo Completo de Entrega

Processo passo a passo

Desenvolvimento

1. Dev cria feature/* a partir da branch desenv
2. Commit seguindo formato correto com chave do ticket
3. Abertura de PR direcionado para a branch desenv
4. Responsável revisa, aprova e faz merge ao final do dia

Build e Deploy

5. Criar versão para iOS, Android, APK e arquivo IOS, armazenando no Drive

Deploy final da sprint da versão estável

6. Segunda-feira: merge de desenv para main, criando versão estável
7. Hotfix: Criado a partir da main para correções críticas, com merge simultâneo em main e desenv

Diagrama do fluxo

feature/* ──→ desenv ──→ main (produção)
                ↑         ↑
                └─ hotfix/*─┘

Legenda:

• feature/* → desenv: Desenvolvimento normal
• desenv → main: Deploy semanal (segunda-feira)
• hotfix/* → main + desenv: Correções críticas (merge simultâneo)