Poucas discussões de time rendem tanto calor e tão pouca luz quanto "qual fluxo de git usar". A boa notícia que abre esta série final: a resposta não é opinião; é função de uma pergunta objetiva: com que frequência você entrega?

GitFlow: o fluxo de quem versiona releases

Publicado por Vincent Driessen em 2010 (nvie.com), o GitFlow organiza o trabalho em branches de papéis fixos: main guarda só versões lançadas; develop acumula o próximo release; features saem de develop; branches de release/ estabilizam a versão; hotfix/ corrige produção por fora.

É uma máquina pensada para um mundo específico: software versionado que se entrega em pacotes: apps mobile esperando revisão de loja, sistemas on-premise instalados em clientes, bibliotecas com versões suportadas em paralelo. Nesse mundo, os papéis fixos pagam a conta: dá para estabilizar a v2.3 enquanto a v2.4 avança, e corrigir a v2.2 do cliente que não atualizou.

O próprio Driessen adicionou uma nota ao post anos depois: para software de entrega contínua, ele recomenda fluxos mais simples. Vale ouvi-lo.

GitHub Flow: o fluxo de quem entrega continuamente

A alternativa cabe em três regras (docs.github.com): main sempre implantável; toda mudança nasce numa branch curta e vira PR; mergeou, implantou. Sem develop, sem release branch, sem cerimônia.

É o par natural da esteira CI/CD que já descrevemos: a versão "instalada" é a última main, o hotfix é... um PR normal (só que rápido), e o rollback é da esteira, não do git. Para produtos web com deploy frequente, a máquina do GitFlow vira atrito puro: develop e main divergindo, merges cerimoniais, releases que agrupam mudanças que podiam já estar no ar.

A régua honesta

• Entrega contínua (web, SaaS, APIs): GitHub Flow. É o padrão do mercado moderno por bons motivos.
• Releases versionadas com suporte paralelo (mobile, on-premise, bibliotecas): GitFlow (ou uma variação enxuta dele: muitos times vivem bem só com main + release/x.y quando precisam estabilizar).
• Times grandes com engenharia forte: o passo além é o trunk-based development (trunkbaseddevelopment.com): branches de horas (não dias) ou commits direto no trunk, com feature flags escondendo o incompleto. É o fluxo com melhor correlação nas pesquisas DORA, e o que exige mais maturidade de testes para sustentar.

O inimigo comum: a branch de longa duração

Qualquer que seja o fluxo, o vilão é o mesmo: a branch que vive semanas. Ela acumula divergência, transforma o merge num evento traumático ("merge hell") e esconde integração, exatamente o que o continuous integration do nome da esteira veio evitar. As regras que valem em todos os fluxos:

1. Branch pequena, vida curta: dias no máximo; o PR revisável agradece.
2. Feature grande se fatia por entregas parciais atrás de flag, não por branch eterna.
3. Sincronize com a main diariamente (rebase ou merge, escolha um e padronize): conflito pequeno todo dia vence conflito monstro no fim.
4. O fluxo se escreve (uma página, estilo ADR): nomes de branch, quem mergeia, como sai hotfix. Implícito, vira folclore divergente.

Migrar é mais fácil do que parece

Times que saem do GitFlow para o GitHub Flow costumam fazer em uma sprint: congela-se o develop, promove-se para main, e as regras novas valem a partir dali. O pré-requisito real não é git; é a esteira confiável que torna "main sempre implantável" verdade, e não slogan.

Desenhar o fluxo para o ritmo real do time (e a esteira que o sustenta) é parte do nosso serviço de DevOps e Deploy. Nos próximos artigos: commits e PRs que contam histórias, e o SemVer sem mistério.

Seu time usa GitFlow para um SaaS de deploy diário? Conte para a IA da Rabelo Digital, aqui no canto da tela, e ela desenha a migração em uma sprint. Sem formulário, sem espera.

---

Leia também

• Commits e PRs que contam histórias
• SemVer: o contrato de três números