Trunk-Based vs GitFlow: Qual Workflow Escolher em 2026

A guerra que nunca acabou

Em 2010, GitFlow era o evangelho. Em 2018, trunk-based development virou o queridinho dos high-performers do State of DevOps Report. Em 2026, ainda tem time se matando em PRs de 5000 linhas que ficam abertos por semanas porque "esse é o nosso processo". Escolher o workflow errado custa tempo, qualidade e moral. Vamos comparar os dois com honestidade.

GitFlow em 2 minutos

Modelo proposto por Vincent Driessen em 2010. Tem branches longas e papeis bem definidos:

• main — só recebe releases de produção, taggeadas.
• develop — branch de integração contínua. Tudo passa por aqui antes de virar release.
• feature/* — saem de develop, voltam pra develop via PR.
• release/* — congelamento pra QA, sai de develop, vai pra main e volta pra develop.
• hotfix/* — emergência, sai de main, volta pra main e develop.

main     ────●────────●───── (releases tagged)
              \      /
release        ●────●
              /      \
develop  ───●────────●───●── (integration)
              \      /  /
feature        ●────●  ●

Quando faz sentido: produtos com versões públicas (apps mobile, software baixável, libs com semver), releases mensais ou trimestrais, time grande com QA dedicado, regulação (banco, healthcare) que exige rastreabilidade de cada release.

Trunk-Based Development em 2 minutos

Modelo defendido por Paul Hammant e popularizado pelo State of DevOps. A ideia é radical: uma única branch principal, integrações pequenas e frequentes.

• main — sempre deployável.
• Devs criam branches curtas (no máximo 1-2 dias de vida) e mergeiam direto em main via PR.
• Features incompletas ficam atrás de feature flags em vez de viver em branches longas.
• Releases são apenas tags em commits específicos de main.

main  ──●──●──●──●──●──●──●──●── (sempre deployável)
         \   \   \      \
          ●   ●   ●      ●  (branches curtas, < 2 dias)

Quando faz sentido: produtos web com deploy contínuo (SaaS, APIs), times que praticam CI/CD de verdade, cobertura de testes razoável, cultura de PR review rápido (< 4h).

Comparação direta

| Critério | GitFlow | Trunk-Based | |---|---|---| | Frequência de deploy | Releases agendadas | Múltiplos por dia | | Tamanho médio de PR | 500-2000 linhas | 50-300 linhas | | Tempo de vida de branch | Dias a semanas | Horas a 2 dias | | Conflitos de merge | Frequentes e dolorosos | Raros | | Necessidade de testes | Pode escapar com manual | Obrigatório automatizado | | Necessidade de feature flags | Baixa | Alta | | Curva de aprendizado | Alta (5+ branch types) | Baixa (1 branch + tags) | | Suporta múltiplas versões em produção? | Sim, naturalmente | Difícil |

O argumento empírico

O State of DevOps Report mede há mais de 10 anos características de times "elite". Os achados consistentes:

• Times elite fazem deploy on-demand (várias vezes ao dia).
• Lead time de commit a produção: menos de 1 hora.
• Falha em produção causada por mudanças: < 5%.
• Tempo de recuperação de incidente: menos de 1 hora.

Esses números são incompatíveis com GitFlow tradicional. Não dá pra fazer 10 deploys/dia se cada release passa por uma branch de QA de 3 dias.

Mas atenção: trunk-based só funciona com automação séria. Se você não tem CI rodando em cada commit, testes confiáveis e capacidade de dar rollback rápido, vai ser um desastre.

O caminho do meio: GitHub Flow

Existe um meio termo bastante usado, conhecido como GitHub Flow:

• main é deployável.
• Devs criam branches por feature, com nomes descritivos (fix/login-bug).
• PR é aberto cedo, mesmo com a feature incompleta (Draft PR).
• Após review e CI verde, merge em main.
• Deploy é automático ou manual logo após o merge.

É basicamente trunk-based com branches um pouco mais longas (até 1 semana). Funciona bem pra times de 5-50 devs em produtos web.

Erros comuns dos dois lados

Em GitFlow

• Branches feature/* que viram zumbi (vivem 2 meses, ninguém mais sabe o estado).
• develop que diverge demais de main porque hotfixes não foram backportados.
• PRs gigantes que ninguém revisa direito ("LGTM" sem ler).
• Esquecer de criar a release/* e jogar tudo direto no main.

Em Trunk-Based

• Mergear código quebrado porque "depois eu arrumo".
• Feature flags que viram dívida técnica eterna (5 anos depois ainda tem if (FLAG_NEW_CHECKOUT) no código).
• Pular review porque "é só uma mudança pequena".
• Não ter capacidade de rollback e quando algo quebra, fica todo mundo refém.

Como decidir pro seu time

Pergunte:

1. Você libera versões agendadas ou faz deploy contínuo?

   • Agendadas → GitFlow ou GitHub Flow
   • Contínuo → Trunk-Based ou GitHub Flow

2. Sua suite de testes pega regressões com confiança?

   • Sim → Trunk-Based viável
   • Não → fique em GitFlow até melhorar testes

3. Você precisa manter múltiplas versões em produção (v1, v2, v3)?

   • Sim → GitFlow
   • Não → Trunk-Based

4. Quanto tempo um PR seu fica esperando review?

   • < 4h → Trunk-Based viável
   • Dias → resolva isso antes de mudar workflow

Conclusão

Não existe workflow "melhor". Existe workflow que combina com a maturidade do seu time. GitFlow é robusto pra contextos rígidos. Trunk-Based é ágil pra contextos modernos. GitHub Flow é o sweet spot pra maioria dos times web. Escolha com base em dados, não em moda. E qualquer que seja a escolha, discipline e automação importam mais que o nome do branch.