Git Flow vs. Trunk Based Development: qual estratégia de branch usar

1. Introdução às Estratégias de Branch no Git

Estratégias de branch no Git são padrões organizacionais que definem como os desenvolvedores criam, nomeiam e mesclam branches durante o ciclo de vida do software. Escolher a estratégia correta é crucial porque impacta diretamente a velocidade de entrega, a qualidade do código e a colaboração da equipe. Duas abordagens antagônicas dominam o debate atual: Git Flow, com sua estrutura rígida e múltiplos branches, e Trunk Based Development (TBD), que prega simplicidade e integração contínua.

Enquanto o Git Flow é ideal para projetos de longo prazo com releases programadas, o TBD brilha em cenários de entrega contínua, onde deploys múltiplos por dia são a norma. A escolha entre eles não é apenas técnica, mas também cultural e organizacional.

2. Git Flow: Estrutura e Funcionamento

Proposto por Vincent Driessen em 2010, o Git Flow define cinco tipos de branches:

  • main: contém o código de produção, sempre estável
  • develop: branch de integração para o próximo release
  • feature/: branches criados a partir de develop para novas funcionalidades
  • release/: preparação de uma nova versão a partir de develop
  • hotfix/: correções urgentes a partir de main

O fluxo típico funciona assim:

# Iniciar uma nova feature
git checkout develop
git checkout -b feature/nova-funcionalidade

# Desenvolver e commitar
git add .
git commit -m "Implementa nova funcionalidade"

# Finalizar a feature (merge em develop)
git checkout develop
git merge --no-ff feature/nova-funcionalidade

# Iniciar um release
git checkout develop
git checkout -b release/1.2.0

# Finalizar o release (merge em main e develop)
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0 -m "Versão 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0

Vantagens:
- Controle granular sobre releases com branches dedicados
- Suporte a múltiplas versões simultâneas (ideal para manutenção de versões legadas)
- Separação clara entre código em desenvolvimento e código estável

3. Trunk Based Development (TBD): Simplicidade e Velocidade

O TBD, defendido por Paul Hammant e a equipe do Google, propõe que todos os desenvolvedores trabalhem em um único branch principal (trunk ou main). As práticas essenciais incluem:

  • Commits pequenos e frequentes (idealmente várias vezes ao dia)
  • Feature flags para isolar código incompleto
  • Testes automatizados robustos para garantir que o trunk nunca quebre

Exemplo de fluxo TBD:

# Atualizar o trunk local
git checkout main
git pull origin main

# Fazer alterações diretamente ou via branch curto
git checkout -b ajuste-pequeno
git add .
git commit -m "Ajusta validação de email"
git checkout main
git merge ajuste-pequeno
git push origin main

Com feature flags, o código incompleto é desabilitado em produção:

// Exemplo de feature flag em JavaScript
if (featureFlags.isEnabled('nova-funcionalidade')) {
    executarNovoFluxo();
} else {
    executarFluxoAntigo();
}

Vantagens:
- Integração contínua real: código é integrado ao trunk várias vezes ao dia
- Redução drástica de conflitos de merge (branches duram horas, não dias)
- Ciclos de feedback rápidos: problemas são detectados minutos após o commit

4. Comparação Direta: Quando Usar Cada Estratégia

Critério Git Flow Trunk Based Development
Tamanho da equipe Times grandes e distribuídos Squads ágeis pequenos (até 10 pessoas)
Frequência de releases Programadas (semanal/mensal) Múltiplos deploys por dia
Complexidade do projeto Produtos com suporte a versões legadas SaaS e aplicações web modernas
Maturidade do processo Equipes maduras com processos bem definidos Equipes experientes em CI/CD
Tolerância a riscos Baixa (releases controladas) Alta (rollback rápido via feature flags)

Git Flow é recomendado quando:
- Você mantém versões antigas do software para clientes específicos
- O ciclo de release é longo (semanas ou meses)
- A equipe é grande e distribuída geograficamente

TBD é recomendado quando:
- Você faz deploys múltiplas vezes ao dia
- A equipe é pequena e co-localizada
- O produto é um SaaS ou aplicação web sem versões legadas

5. Desafios e Armadilhas Comuns

Git Flow:
- Branches longos geram conflitos massivos e dificuldade de integração
- Complexidade desnecessária para equipes pequenas
- Dificuldade em fazer hotfixes rápidos sem interromper o fluxo

TBD:
- Exige disciplina rigorosa em testes automatizados (cobertura acima de 80%)
- Feature flags precisam ser gerenciadas e removidas após estabilização
- Qualquer commit quebrado no trunk afeta toda a equipe imediatamente

Mitigação:
- Use pull requests curtos (máximo 200 linhas) com revisão obrigatória
- Implemente pipelines de CI/CD robustos com testes unitários, de integração e E2E
- Estabeleça branch policies que bloqueiem merges sem aprovação e sem testes verdes

6. Híbrido e Adaptações: Estratégias Personalizadas

GitHub Flow: simplificação do Git Flow com apenas main e feature branches. Ideal para equipes que querem mais estrutura que o TBD puro, mas menos complexidade que o Git Flow.

# Fluxo GitHub Flow
git checkout -b feature/ajuste-ui
git commit -m "Ajusta layout responsivo"
git push origin feature/ajuste-ui
# Abrir Pull Request no GitHub
# Após aprovação, fazer merge em main
git checkout main
git pull origin main

GitLab Flow: combina branches de ambiente (ex.: staging, production) com trunk. Útil quando há necessidade de ambientes intermediários antes da produção.

A chave é adaptar a estratégia à cultura da empresa sem rigidez dogmática. Muitas equipes bem-sucedidas usam uma abordagem híbrida: TBD para o dia a dia com branches de release para versões específicas.

7. Implementação Prática: Exemplos de Comandos e Ferramentas

Git Flow com Git Extensions (instale git-flow primeiro):

# Inicializar git-flow no repositório
git flow init

# Iniciar uma feature
git flow feature start autenticacao-2fa

# Finalizar a feature (merge automático em develop)
git flow feature finish autenticacao-2fa

# Iniciar um release
git flow release start 2.0.0

# Finalizar o release (merge em main e develop, com tag)
git flow release finish 2.0.0

TBD com proteção de branch no GitHub:

# Configurar branch protection rule via GitHub CLI
gh api repos/:owner/:repo/branches/main/protection \
  --method PUT \
  --field required_status_checks='{"strict":true,"contexts":["continuous-integration/jenkins","code-review"]}' \
  --field enforce_admins=true \
  --field required_pull_request_reviews='{"required_approving_review_count":1}'

Feature flags com LaunchDarkly (exemplo em Python):

import ldclient
from ldclient.config import Config

ldclient.set_config(Config("sdk-key-12345"))
client = ldclient.get_client()

if client.variation("nova-funcionalidade", {"key": "user-1"}, False):
    print("Nova funcionalidade ativada")
else:
    print("Fluxo antigo")

8. Conclusão e Recomendações Finais

A escolha entre Git Flow e Trunk Based Development resume-se a um trade-off entre complexidade vs. simplicidade e controle vs. velocidade. O Git Flow oferece controle granular sobre releases e suporte a múltiplas versões, mas com custo de complexidade operacional. O TBD oferece velocidade e integração contínua real, mas exige disciplina técnica e cultural.

Critérios objetivos para escolha:
1. Frequência de deploy: se for diária ou múltiplas vezes ao dia, escolha TBD
2. Maturidade da equipe: times experientes em CI/CD se beneficiam mais do TBD
3. Suporte a versões: se você precisa manter versões antigas, Git Flow é quase obrigatório

Minha recomendação final: comece com TBD se a equipe tiver até 10 pessoas e o produto for SaaS. Evolua para Git Flow (ou um híbrido como GitHub Flow) conforme a equipe crescer e a necessidade de suporte a versões surgir. Lembre-se: a melhor estratégia é aquela que sua equipe consegue seguir consistentemente.

Referências