Estratégias de Branching Git: Gitflow vs Trunk-Based vs GitHub Flow

Branching Git: Não Existe Uma Única Maneira Certa

Todo time discute sobre estratégias de branching em algum momento. A verdade é que não existe melhor abordagem universal — depende do tamanho do time, cadência de releases e modelo de deploy. Aqui estão as três estratégias mais populares com trade-offs honestos.

GitHub Flow (Simples)

main ─────●─────●─────●─────●─────●─────
            \         /
             feature ●

Como funciona:

Crie branch a partir de main
Faça commits, push para remoto
Abra um pull request
Receba code review
Merge para main
main está sempre deployável

git checkout -b feature/add-search
# ... trabalhe, commite, push ...
git push -u origin feature/add-search
# Abra PR no GitHub, receba review, merge

Prós	Contras
Simples — uma regra de branch	Sem separação entre "lançado" e "em progresso"
Iteração rápida	Requer maturidade de CI/CD (deploy automático no merge)
Funciona ótimo para SaaS / web apps	Mais difícil para apps mobile com ciclos de release

Melhor para: Times pequenos, produtos SaaS, deploy contínuo.

Gitflow (Complexo)

main     ─────●───────────────●───────
              |               |       
release       |    ●────●     |       
              |   /      \    |       
develop ──●──●──●────●────●──●───●──
           \      /       \      /    
feature     ●───●          ●───●

Como funciona:

main — apenas releases de produção, taggeado com versões
develop — branch de integração, sempre tem as features mais recentes
feature/* — branch de develop, merge de volta para develop
release/* — branch de develop quando pronto para release, apenas bug fixes
hotfix/* — branch de main para fixes urgentes de produção

Prós	Contras
Clara separação de responsabilidades	Muitas branches e cerimônia
Gerenciamento explícito de releases	Conflitos de merge acumulam no develop
Bom para software versionado	Lento — features esperam janelas de release

Melhor para: Software empacotado, apps mobile com releases na app store, times com estágios de QA.

Trunk-Based Development (Rápido)

main ──●──●──●──●──●──●──●──●──●──
        \  /   \  /
         ●      ●
      (branches curtas, < 1 dia)

Como funciona:

Todos commitam em main (ou branches muito curtas mergidas no mesmo dia)
Feature flags escondem trabalho incompleto
CI roda em todo commit
Releases são tags em main, ou deploy contínuo

# Branch de vida curta (mergida em horas)
git checkout -b fix/typo-in-header
git commit -am "Fix typo in header component"
git push -u origin fix/typo-in-header
# PR criado, revisado, mergido no mesmo dia

# Ou commitar direto em main (com proteção CI)
git commit -am "Add search endpoint behind feature flag"
git push origin main

Prós	Contras
Loop de feedback mais rápido	Requer excelente CI/CD e testes
Sem inferno de merge	Feature flags adicionam complexidade
Usado por Google, Meta, etc.	Requer disciplina do time

Melhor para: Times experientes, deploy contínuo, microsserviços.

Comparação

Fator	GitHub Flow	Gitflow	Trunk-Based
Complexidade	Baixa	Alta	Baixa
Vida da branch	Dias	Dias a semanas	Horas
Conflitos de merge	Ocasionais	Frequentes	Raros
Modelo de release	Contínuo	Agendado	Contínuo
Maturidade CI/CD necessária	Média	Baixa	Alta
Tamanho do time	2-15	5-50+	Qualquer (com disciplina)

Dicas Práticas

Mantenha branches de vida curta. Qualquer branch aberta por mais de 3 dias é um conflito de merge esperando acontecer.
Delete branches após merge. git branch -d feature/done e habilite auto-delete no GitHub.
Proteja main. Exija PR reviews e CI passando antes do merge.
Rebase antes de mergear para manter histórico limpo: git rebase main na sua feature branch.
Use conventional commits para changelogs automatizados: feat:, fix:, chore:.

Referência Git: Cheatsheet Git — todos os comandos git comuns, pesquisáveis e categorizados.