1. Visão geral dos modelos de branching

Em equipes de software, o modelo de branching dita como as mudanças chegam ao produto final. O Git Flow preconiza ramos bem definidos para features, releases e hotfixes, com ciclos de integração mais previsíveis e planejamento de releases. O trunk-based development aposta em um tronco único (main) e integrações frequentes de mudanças pequenas, com validação contínua por meio de CI/CD e toggles de feature para controlar a visibilidade de novas funcionalidades.

Pontos-chave a considerar:

• Cadência de releases: Git Flow costuma associar releases em janelas regulares; trunk-based favorece releases mais frequentes e, por vezes, contínuos.
• Risco de conflito: ramos longos em Git Flow podem acumular conflitos difíceis de resolver; trunk-based minimiza isso por meio de integrações frequentes.
• Governança: projetos sujeitos a compliance podem exigir ramos formais; equipes ágeis valorizam velocidade com controle por meio de testes e feature flags.

2. Git Flow: arquitetura de ramos e operações típicas

Git Flow introduz ramos estáveis para diferentes fases do ciclo de vida:

• Main (ou Master): agregado das releases estáveis.
• Develop: integração de features em desenvolvimento; aqui o trabalho de longo prazo fica consolidado antes da release.
• Feature branches: criados a partir de Develop para cada nova funcionalidade e fechados ao término.
• Release branches: preparações para a release, com correções de última hora.
• Hotfix branches: correções emergenciais em produção, criadas a partir do Main.

Vantagens:

• Clareza de fases: cada tipo de mudança tem um ramo específico.
• Controle de release: patches de produção isolados sem interromper o desenvolvimento em curso.

Desvantagens:

• Complexidade operacional: gestão de múltiplos ramos pode exigir políticas rigorosas e ferramentas de automação.
• Integração cumulativa: merges entre muitos ramos podem gerar conflitos significativos.

3. Trunk-based development: fluxo enxuto com validação contínua

No trunk-based, o tronco único (geralmente main) recebe integrações frequentes. Práticas-chave:

• Commits pequenos e frequentes: mudanças pequenas reduzem o risco de conflitos e facilitam a revisão.
• Branches curtos quando necessários: ramos de curta duração apenas para tarefas claramente limitadas, com mesclagens rápidas.
• Feature flags: novas funcionalidades podem ficar desativadas até atingirem a aprovação, promovendo entrega segura sem branches longos.
• CI/CD maturado: validação automática de cada commit (build, testes, segurança) antes da integração ao main.

Vantagens:

• Entrega rápida e frequente, com feedback rápido do usuário e do sistema.
• Redução de dívidas de integração devido à fusão contínua e a menor distância entre branches.

Desvantagens:

• Presente demanda por disciplina da equipe: commits bem feitos, testes extensivos e revisões rápidas.
• Risco de toggles mal gerenciados: flags podem acumular technical debt se não acompanhadas de limpeza.

4. Comparativo prático e diretrizes de escolha

Como decidir entre git-flow e trunk-based development? Veja alguns gatilhos comuns:

• Equipe pequena e release frequente: trunk-based tende a ser mais ágil, com automação robusta de CI/CD.
• Grande base de código com dependências complexas: git-flow pode oferecer maior controle de release e governança.
• Conformidade regulatória: políticas formais de aprovação e auditoria costumam favorecer ramos bem definidos (git-flow).
• Necessidade de isolamento de riscos: hotfixes rápidos em produção funcionam melhor com ramos dedicados (git-flow) ou com feature flags em trunk-based.

Estratégia de migração gradual (quando aplicar):

• Mapeie os ciclos de entrega atuais e identifique gargalos de integração.
• Implemente CI/CD estável e testes automatizados como base de qualquer modelo.
• Para trunk-based: introduza feature flags para itens em desenvolvimento e reduza hacks de merge.
• Para git-flow: comece definindo policy de merges, automação de hooks e processos de release com releases regulares.

Exemplo de fluxo (resumo técnico)

Sequência resumida de comandos para ilustrar ambos os modelos. Observação: adapte conforme suas ferramentas de CI/CD e políticas de merge.

// Git Flow (fluxo tradicional)
git flow init -d
git flow feature start user-auth
// trabalhar na feature...
git flow feature finish user-auth
git flow release start 1.0.0
// validações, correções rápidas
git flow release finish 1.0.0

// Trunk-based development (fluxo enxuto)
git checkout main
git pull origin main
git checkout -b feat/user-auth
// desenvolver, fazer commits pequenos
git push origin feat/user-auth
// após CI validar, mesclar de volta ao trunk
git checkout main
git merge --ff-only feat/user-auth
git push origin main
// (opcional) criar release via tagging
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin --tags