Git Flow: o que é, modelo de ramificação e uso em projetos

O que é Git Flow?

Git Flow é um modelo de ramificação Git que define uma estrutura estrita de branches e regras de mesclagem para gerenciar desenvolvimento, lançamentos e correções. Vincent Driessen publicou o artigo “A successful Git branching model” em janeiro de 2010, e desde então Git Flow se tornou o padrão de facto no desenvolvimento corporativo Java e .NET. A ideia principal é dividir o código em cinco tipos de branches com diferentes níveis de estabilidade.

De acordo com Atlassian Git Tutorials, 2024, Git Flow é baseado em duas branches perpétuas: main (anteriormente master) e develop. Todas as outras branches são temporárias: feature, release, hotfix. Cada tipo de branch tem um ciclo de vida e regras de mesclagem claramente definidos. No desenvolvimento móvel, Git Flow é usado em projetos com ciclos de lançamento regulares (2–4 semanas) e suporte a múltiplas versões.

Git Flow difere de modelos simples (GitHub Flow) por exigir uma branch develop separada para integração. Isso adiciona uma etapa ao processo de mesclagem, mas fornece isolamento adicional de funcionalidades inacabadas do código pronto para lançamento.

Vincent Driessen e a história do Git Flow

Em 2010, Vincent Driessen publicou o post “A successful Git branching model”, que se tornou um dos mais citados na história do Git. O modelo foi criado para um projeto com lançamentos fixos e suporte paralelo de versões. Em 2020, Driessen reconheceu que o Git Flow está desatualizado para práticas modernas de CI/CD, mas o modelo continua relevante para projetos com ciclos de lançamento longos e necessidade de suportar versões antigas.

# Inicializar Git Flow
git flow init

# Criar uma branch feature
git flow feature start "add-auth"

# Finalizar branch feature (mesclar em develop)
git flow feature finish "add-auth"

# Criar um release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Branch Main: código de lançamento e marcação

Main (anteriormente master) é a branch principal que contém apenas código de lançamento pronto para implantação. Cada commit em main deve corresponder a uma versão específica do produto, marcada com o formato de versionamento semântico, por exemplo v1.0.0, v1.1.0. Nenhum desenvolvimento direto é feito em main — as mudanças chegam aqui apenas através de branches release ou hotfix.

De acordo com semver.org, 2024, as tags em main usam o formato MAJOR.MINOR.PATCH. MAJOR é incrementado para mudanças incompatíveis na API, MINOR para adição de funcionalidades com compatibilidade reversa, PATCH para correção de bugs. No Git Flow, cada finalização de release cria automaticamente um commit em main com uma tag de versão.

A branch Main é a única que vai para produção. Para projetos móveis, isso significa que um push em main aciona o pipeline de construção do App Bundle ou IPA e publicação no Google Play / App Store. Nas configurações de CI/CD do GitLab, main é protegida contra force-push e exclusão.

Versionamento semântico e tags

Cada commit em main é acompanhado por uma tag no formato SemVer: vMAJOR.MINOR.PATCH. MAJOR — para mudanças incompatíveis na API, MINOR — para novas funcionalidades com compatibilidade reversa, PATCH — para correção de bugs. Exemplo: v2.1.0 significa o segundo lançamento principal com novas funcionalidades e sem correções de bugs. No Git Flow, as tags são criadas automaticamente ao finalizar um release ou hotfix através do comando git flow release finish.

Branch Develop: linha de integração do desenvolvimento

Develop é a segunda branch perpétua no Git Flow, projetada para integrar todas as funcionalidades concluídas. Os desenvolvedores mesclam branches feature em develop após passar pela revisão de código e verificacoes de CI/CD. Develop contém a versão estável mais recente do código, incluindo todas as funcionalidades implementadas do sprint atual.

De acordo com DataSift Git Flow Guide, 2024, develop pode estar temporariamente instável devido a integrações em andamento. Para evitar problemas, as equipes praticam Integração Contínua (CI): cada funcionalidade deve passar por um conjunto completo de testes antes de ser mesclada em develop. Se a CI falhar, o desenvolvedor corrige o código antes da próxima mesclagem. Develop está sempre vinculada à versão atual de main: imediatamente após um lançamento, develop é sincronizada com main através de uma mesclagem.

Branches Feature: desenvolvimento de novas funcionalidades

Branches Feature são branches temporárias para desenvolver funcionalidades individuais, correções de bugs ou experimentos. Cada branch feature é criada a partir de develop e mesclada de volta em develop após a conclusão. O nome da branch feature geralmente contém o número da tarefa ou uma breve descrição: feature/APP-123-add-oauth, feature/redesign-profile. No Git Flow, as branches feature podem existir por tempo indeterminado.

De acordo com Pro Git Book, 2024, branches feature são um ambiente de desenvolvimento isolado: mudanças em uma branch não afetam outras até a mesclagem. Em projetos móveis, as branches feature são sincronizadas com develop via rebase ou merge para evitar grandes conflitos na finalização. Recomenda-se fazer rebase da branch feature em develop antes de criar um MR.

# Criação manual de branch feature (sem git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Criar MR no GitLab via CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Branches Release: preparação de um lançamento

Branches Release são branches temporárias criadas a partir de develop para preparar um lançamento. Quando develop contém funcionalidades suficientes para uma nova versão, a equipe cria uma branch release/X.Y.Z (por exemplo, release/2.1.0). Nesta branch são feitas apenas alterações finais: incremento de versão, atualização de localização, testes finais, correção de bugs críticos.

De acordo com Atlassian Git Tutorials, 2024, a branch release resolve um problema fundamental: isolar alterações finais do desenvolvimento paralelo. Enquanto o lançamento está sendo preparado, novas funcionalidades para o próximo lançamento continuam sendo mescladas em develop. Após a conclusão, a branch release é mesclada em main (com uma tag) e em develop (para sincronizar o incremento de versão).

Branches Hotfix: correções urgentes em produção

Branches Hotfix são branches temporárias para corrigir urgentemente bugs críticos em produção. O único tipo de branch no Git Flow que é criado a partir de main em vez de develop. Formato do nome: hotfix/X.Y.Z+1 (por exemplo, hotfix/2.1.1). Após a conclusão, a branch hotfix é mesclada simultaneamente em main (como um novo patch release) e em develop (para que a correção não se perca em lançamentos futuros).

De acordo com DataSift Git Flow Guide, 2024, as branches hotfix devem ser as mais curtas possível — apenas a correção e o teste. Um hotfix não deve incluir novas funcionalidades ou refatoração. No desenvolvimento móvel, hotfix é usado para corrigir falhas críticas (taxa de crash > 0,1%), vulnerabilidades de segurança ou bugs bloqueadores na App Store.

Prós e contras do Git Flow para desenvolvimento móvel

Git Flow fornece uma estrutura clara que é especialmente útil para grandes equipes e projetos com lançamentos regulares. Prós: isolamento de funcionalidades inacabadas em branches feature, capacidade de preparar um lançamento sem bloquear o desenvolvimento, suporte a múltiplas versões via hotfix. Contras: complexidade para iniciantes, necessidade de rebase regular das branches feature, conflitos com branches de longa duração.

De acordo com Martin Fowler, 2024, a principal desvantagem do Git Flow são as branches feature de longa duração. Se uma funcionalidade é desenvolvida por 2+ semanas sem sincronização com develop, o conflito de mesclagem se torna significativo. Para projetos móveis, recomenda-se sincronizar a branch feature diariamente via rebase em develop.

Git Flow não é recomendado para projetos com Continuous Deployment (cada commit em main → produção). Para tais projetos, GitHub Flow ou Trunk-Based Development fornecem um modelo mais simples e rápido. Mas para projetos com ciclos de lançamento e suporte a versões antigas, Git Flow continua sendo a escolha ideal.

Quando o Git Flow é prejudicial para a equipe

Git Flow se torna um problema em três casos: equipes com menos de 5 pessoas (complexidade desnecessária), Continuous Deployment (atraso na entrega), falta de disciplina de rebase (branches feature de longa duração criam conflitos de mesclagem). Se uma equipe gasta mais de 20% do tempo mesclando branches e resolvendo conflitos — Git Flow não é adequado para essa equipe, mesmo que seja grande.

Alternativas ao Git Flow: GitHub Flow e Trunk-Based Development

Alternativas ao Git Flow oferecem um processo mais simples para equipes que praticam CI/CD. GitHub Flow usa apenas uma branch perpétua (main) e branches feature. Cada funcionalidade é criada a partir de main, após revisão e CI é mesclada de volta em main e imediatamente implantada. GitHub Flow é mais simples mas não suporta isolamento de funcionalidades inacabadas ou preparação paralela de lançamentos.

De acordo com GitHub Docs, 2024, Trunk-Based Development (TBD) vai ainda mais longe: todos os desenvolvedores trabalham em uma única branch (trunk), usando branches feature de curta duração de 1–2 dias. Feature toggles controlam a visibilidade do código inacabado. TBD exige alta disciplina de CI/CD e automação de testes.

• GitHub Flow — uma main + branches feature, ideal para CI/CD e equipes pequenas
• GitLab Flow — estende Git Flow com branches de ambiente (staging, production)
• Trunk-Based Development — uma branch + feature toggles, máximo CI/CD, mínimas mesclagens
• One Flow — Git Flow simplificado sem branch develop, apenas main + feature + release