O Git é uma ferramenta poderosa para controle de versão, mas seu verdadeiro potencial é alcançado quando combinado com um fluxo de trabalho bem definido. Um fluxo de trabalho (ou branching model) estabelece regras sobre como e quando criar branches, fazer merges e realizar releases. Nesta aula, vamos explorar três dos modelos mais populares: GitFlow, Trunk-based development e Feature branches. Cada um tem suas particularidades e se adequa a diferentes contextos de desenvolvimento e entrega.

Entender esses fluxos é essencial para qualquer profissional de DevOps, pois impacta diretamente a integração contínua, a entrega contínua e a qualidade do software. Vamos analisar cada modelo em detalhes, com exemplos práticos de comandos Git, e ao final faremos uma comparação para ajudar na escolha.

GitFlow

O GitFlow é um modelo de branching criado por Vincent Driessen em 2010. Ele define uma estrutura rígida de branches com papéis específicos: master (ou main) para produção, develop para integração, feature branches para novas funcionalidades, release branches para preparar releases, e hotfix branches para correções urgentes. Esse modelo é ideal para projetos com ciclos de release planejados e versões com suporte de longo prazo.

No GitFlow, o branch master sempre reflete o código em produção, enquanto o develop contém as últimas alterações integradas. As features são desenvolvidas em branches separadas a partir de develop e mescladas de volta quando prontas. Quando uma release é planejada, um branch release é criado a partir de develop para ajustes finais e, após aprovado, é mesclado em master e develop. Hotfixes são criados a partir de master e mesclados em ambos os branches.

Exemplo prático:

# Criar branch develop a partir de master
git checkout -b develop master

# Criar feature branch
git checkout -b feature/nova-funcionalidade develop

# Trabalhar na feature, commitar e, ao final, mesclar de volta
git checkout develop
git merge --no-ff feature/nova-funcionalidade
git branch -d feature/nova-funcionalidade

# Criar release branch
git checkout -b release/1.0 develop
# Ajustar versão, corrigir bugs, etc.
git checkout master
git merge --no-ff release/1.0
git tag -a v1.0 -m "Versão 1.0"
git checkout develop
git merge --no-ff release/1.0
git branch -d release/1.0

# Hotfix
git checkout -b hotfix/1.0.1 master
git commit -m "Correção crítica"
git checkout master
git merge --no-ff hotfix/1.0.1
git tag -a v1.0.1 -m "Hotfix 1.0.1"
git checkout develop
git merge --no-ff hotfix/1.0.1
git branch -d hotfix/1.0.1

Trunk-based development

O Trunk-based development (TBD) é um modelo mais simples, onde todos os desenvolvedores trabalham em um único branch principal (trunk), geralmente main ou master. As alterações são integradas com frequência, várias vezes ao dia, e os branches de feature são curtos e de curta duração (horas ou dias). Esse modelo é amplamente adotado em equipes que praticam CI/CD, pois reduz a complexidade de merge e acelera a entrega.

No TBD, não existem branches de release ou hotfix separados; as releases são feitas a partir do trunk, muitas vezes usando tags ou releases automáticas. Para isolar funcionalidades incompletas, usa-se feature flags (toggle) em vez de branches longos. Isso permite que o código seja integrado continuamente sem quebrar a estabilidade.

Exemplo prático:

# Atualizar o trunk
git checkout main
git pull origin main

# Criar um branch curto para uma alteração
git checkout -b fix/pequeno-ajuste
# Fazer commit e push
git commit -m "Ajuste na validação"
git push origin fix/pequeno-ajuste

# Criar pull request e, após aprovação, mesclar (merge squash ou rebase)
# No TBD, é comum usar merge squash para manter histórico linear

# Após merge, deletar o branch remoto e local
git branch -d fix/pequeno-ajuste
git push origin --delete fix/pequeno-ajuste

# Para releases, basta criar uma tag no main
git tag -a v2.0 -m "Release 2.0"
git push origin v2.0

Feature branches

O modelo de Feature branches é uma abordagem mais flexível, onde cada nova funcionalidade é desenvolvida em um branch separado, criado a partir do branch principal (geralmente main ou develop). Diferente do GitFlow, não há branches fixos para release ou hotfix; cada equipe define sua própria estrutura. Esse modelo é comum em equipes que usam pull requests para revisão de código.

As feature branches podem ter duração variável, de dias a semanas. Ao final, são mescladas de volta ao branch principal, geralmente via merge ou rebase. Uma prática recomendada é manter os branches atualizados com o branch principal para evitar conflitos grandes.

Exemplo prático:

# A partir do branch principal
git checkout main
git pull origin main

# Criar feature branch
git checkout -b feature/autenticacao-2fa

# Trabalhar e commitar
git add .
git commit -m "Adiciona autenticação 2FA"
git push origin feature/autenticacao-2fa

# Manter sincronizado com main
git fetch origin
git rebase origin/main
# ou git merge origin/main

# Abrir pull request e, após aprovação, mesclar
git checkout main
git merge --no-ff feature/autenticacao-2fa
git push origin main

# Deletar branch local e remoto
git branch -d feature/autenticacao-2fa
git push origin --delete feature/autenticacao-2fa

Comparação

A escolha do fluxo de trabalho depende de fatores como frequência de releases, tamanho da equipe, necessidade de suporte a versões antigas e maturidade em CI/CD. A tabela abaixo resume as principais diferenças:

  • GitFlow: Releases planejadas, suporte a múltiplas versões, maior complexidade. Adequado para projetos com versões de longo prazo e equipes grandes.
  • Trunk-based development: Releases contínuas, simplicidade, integração frequente. Ideal para equipes que praticam CI/CD e deploys múltiplos por dia.
  • Feature branches: Flexibilidade, equilíbrio entre isolamento e integração. Bom para equipes que precisam de revisão de código e não querem a rigidez do GitFlow.

Na prática, muitos times adotam uma abordagem híbrida, por exemplo, usando feature branches curtos com trunk-based development, ou GitFlow com releases frequentes. O importante é que o fluxo seja documentado e seguido por toda a equipe.

Boas práticas

  • Mantenha os branches de curta duração para evitar conflitos grandes.
  • Sempre atualize seu branch com o branch principal antes de mesclar.
  • Use mensagens de commit claras e padronizadas.
  • Automatize a integração contínua para validar cada push.
  • Revise o código via pull requests, mesmo em TBD.

Referências

Exercícios

  1. Qual a principal diferença entre GitFlow e Trunk-based development em relação à frequência de integração?

    ✓ Resposta: No GitFlow, a integração é menos frequente, geralmente ao final de cada feature ou release. No Trunk-based development, a integração ocorre várias vezes ao dia, com branches de curta duração.

  2. No GitFlow, qual branch é usado como base para criar um branch de release?

    ✓ Resposta: O branch de release é criado a partir do branch develop.

  3. Qual técnica é frequentemente usada no Trunk-based development para isolar funcionalidades incompletas?

    ✓ Resposta: Feature flags (ou toggles).

  4. No modelo de Feature branches, qual comando Git pode ser usado para manter o branch atualizado com o branch principal?

    ✓ Resposta: git rebase origin/main ou git merge origin/main.

  5. Cite uma vantagem do GitFlow em relação ao Trunk-based development.

    ✓ Resposta: O GitFlow oferece suporte explícito a múltiplas versões de produção (via branches de release e hotfix), facilitando correções em versões antigas.