Branch strategies: GitHub Flow e Trunk-Based Development

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, fundem e mantêm branches ao longo do ciclo de desenvolvimento de software. O objetivo principal é garantir organização, permitir paralelismo no trabalho e manter a estabilidade do código principal.

Historicamente, o Git Flow foi uma das primeiras estratégias amplamente adotadas, com múltiplas branches de longa duração (develop, release, hotfix). Porém, para equipes que praticam integração e entrega contínuas (CI/CD), essa complexidade se mostrou excessiva. Surgiram então abordagens mais enxutas: o GitHub Flow e o Trunk-Based Development (TBD).

Ambas as estratégias simplificam o fluxo ao reduzir o número de branches permanentes, mas diferem em práticas de integração, duração das branches e políticas de merge.

2. GitHub Flow: Simplicidade e Fluxo Contínuo

O GitHub Flow, proposto oficialmente pelo GitHub em 2011, é uma estratégia minimalista baseada em apenas uma branch principal (main) e branches de feature temporárias.

Estrutura básica

  • Branch main: única branch de longa duração. Sempre deve estar em estado deployável.
  • Branches de feature: criadas a partir de main para cada nova funcionalidade ou correção.

Ciclo de vida de uma feature

  1. Criar uma branch a partir de main:
    text git checkout main git pull origin main git checkout -b feature/autenticacao-oauth

  2. Realizar commits incrementais:
    text git add . git commit -m "Adiciona modelo de usuário para OAuth" git commit -m "Implementa fluxo de login com Google"

  3. Enviar a branch para o repositório remoto:
    text git push origin feature/autenticacao-oauth

  4. Abrir um Pull Request (PR) no GitHub.

  5. Realizar code review e discussão diretamente no PR.

  6. Após aprovação, fazer merge para main (geralmente com merge commit ou squash merge).

  7. Deletar a branch de feature (remota e local).

Regras de merge

  • Pull request obrigatório com pelo menos um revisor.
  • CI deve passar antes do merge.
  • Merge direto para main (sem branches intermediárias).

3. Vantagens e Desvantagens do GitHub Flow

Vantagens

  • Baixa complexidade: apenas duas branches ativas por vez (main + feature).
  • Deploy contínuo: main está sempre pronta para produção.
  • Ideal para CI/CD: integração com GitHub Actions é nativa.
  • Code review integrado: PRs são o centro da colaboração.

Desvantagens

  • Risco de instabilidade: se uma feature grande demorar dias para ser revisada, main pode ficar desatualizada.
  • Dificuldade com múltiplas versões: não suporta releases simultâneas (ex: versão 1.x e 2.x).
  • Conflitos frequentes: branches long-lived (mais de 2 dias) tendem a gerar conflitos complexos.

Casos de uso

  • Projetos web com deploy contínuo.
  • SaaS (Software as a Service) com uma única versão em produção.
  • Equipes enxutas (2 a 10 desenvolvedores).

4. Trunk-Based Development (TBD): Integração Frequente

Trunk-Based Development é uma estratégia onde todos os desenvolvedores integram suas mudanças diretamente no "tronco" (main ou trunk) várias vezes ao dia.

Conceito de "tronco único"

  • Branch main: única fonte da verdade. Todos os commits vão para ela.
  • Short-lived branches: duração máxima de algumas horas, nunca mais que um dia.

Práticas fundamentais

  1. Commits pequenos e frequentes: cada commit representa uma mudança atômica e funcional.

  2. Feature flags: funcionalidades incompletas são desabilitadas por flags em produção.

  3. Branches de release opcionais: algumas equipes criam branches de release para estabilizar versões, mas o TBD puro evita isso.

Diferenças entre TBD puro e TBD com branches de release

Aspecto TBD Puro TBD com Release Branches
Branches Apenas main main + branches de release
Deploy Direto de main Da branch de release
Complexidade Mínima Moderada

5. Vantagens e Desvantagens do Trunk-Based Development

Vantagens

  • Redução drástica de conflitos: integração contínua evita divergências.
  • Feedback rápido: problemas são detectados em minutos, não em dias.
  • Deploy contínuo: main está sempre pronta para produção.
  • Maior produtividade: menos tempo resolvendo conflitos, mais tempo codificando.

Desvantagens

  • Disciplina rigorosa: exige commits pequenos e testes unitários abrangentes.
  • Feature flags obrigatórias: código incompleto precisa ser ocultado em produção.
  • Curva de aprendizado: equipes acostumadas com Git Flow podem estranhar.
  • CI robusta necessária: sem testes automatizados, o risco de quebrar main é alto.

Casos de uso

  • Times maduros com alta automação de testes.
  • Empresas que fazem deploy múltiplas vezes ao dia (Google, Netflix, Facebook).
  • Equipes de 10 a 50 desenvolvedores com forte cultura de CI.

6. Comparação Prática: GitHub Flow vs. TBD

Critério GitHub Flow Trunk-Based Development
Duração das branches Dias (2-5 dias) Horas (máximo 1 dia)
Política de merge PR obrigatório com code review Commit direto ou PR rápido
Uso de feature flags Opcional Obrigatório
CI/CD Suporta CI/CD Exige CI/CD forte
Tamanho da equipe 2-10 desenvolvedores 5-50 desenvolvedores
Risco de conflitos Moderado Baixo

Quando escolher cada estratégia

  • Equipe de 5 desenvolvedores, produto web simples: comece com GitHub Flow. A simplicidade compensa.
  • Equipe de 50 desenvolvedores, microserviços, deploy 10x/dia: TBD é a escolha natural.
  • Equipe de 15 desenvolvedores, app mobile com releases trimestrais: GitHub Flow com branches de release pode funcionar.

7. Exemplos de Fluxo de Trabalho com Comandos Git

GitHub Flow: feature completa

# Desenvolvedor A cria uma branch de feature
git checkout main
git pull origin main
git checkout -b feature/pagamento-pix

# Trabalha na funcionalidade
echo "implementacao pix" > pagamento.py
git add pagamento.py
git commit -m "Adiciona módulo de pagamento PIX"

# Envia para o repositório remoto
git push origin feature/pagamento-pix

# Abre Pull Request no GitHub (via interface web)
# Após aprovação, faz merge (via botão no GitHub)
# Deleta a branch remota
git branch -d feature/pagamento-pix
git push origin --delete feature/pagamento-pix

Trunk-Based Development: commits frequentes

# Desenvolvedor B trabalha diretamente na main (ou branch de curta duração)
git checkout main
git pull origin main

# Commit pequeno 1: adiciona teste unitário
echo "test_pix.py" > tests/test_pagamento.py
git add tests/test_pagamento.py
git commit -m "Adiciona teste unitário para pagamento PIX"

# Commit pequeno 2: implementa funcionalidade com feature flag
echo "if FEATURE_PIX_ENABLED:" >> pagamento.py
git add pagamento.py
git commit -m "Implementa pagamento PIX com feature flag"

# Push direto para main (com proteção de branch configurada)
git push origin main

Simulação de conflito e resolução

Cenário GitHub Flow: conflito ao fazer merge do PR.

# Na branch de feature
git checkout feature/pagamento-pix
git merge main  # Atualiza com main
# Resolver conflitos manualmente
git add .
git commit -m "Resolve conflitos com main"
git push origin feature/pagamento-pix
# Agora o PR pode ser mergeado

Cenário TBD: conflito ao fazer push para main.

git checkout main
git pull origin main
# Conflito detectado
git merge --abort  # Interrompe merge
# Resolver localmente, commitar novamente
git add .
git commit -m "Resolve conflito no módulo de pagamento"
git push origin main

8. Conclusão e Boas Práticas

Tanto o GitHub Flow quanto o Trunk-Based Development são estratégias modernas que abandonam a complexidade do Git Flow em favor de simplicidade e integração contínua. A escolha entre elas depende do nível de maturidade da equipe e da frequência de deploy desejada.

Recomendação prática:

  • Comece com GitHub Flow: é mais intuitivo, oferece code review obrigatório e funciona bem para equipes pequenas.
  • Evolua para TBD quando a equipe estiver madura em testes automatizados, feature flags e CI/CD.

Boas práticas universais:

  1. Configure proteção de branches no GitHub (exigir CI, revisão obrigatória).
  2. Use hooks do Git (pre-commit, pre-push) para validar código antes do commit.
  3. Mantenha commits atômicos: um commit = uma mudança lógica.
  4. Documente a estratégia no repositório (CONTRIBUTING.md).

Lembre-se: a melhor estratégia é aquela que sua equipe consegue seguir consistentemente.

Referências