Escolhendo uma Estratégia de Ramificação

O desenvolvimento baseado em trunk leva o princípio "branches devem ter vida curta" à sua conclusão lógica: branches vivem horas, não dias. Engenheiros enviam mudanças pequenas e incrementais para a main várias vezes por dia, usando feature flags para ocultar trabalho incompleto dos usuários.

As vantagens são reais. Problemas de integração surgem imediatamente porque os branches nunca se distanciam muito da main. As execuções de CI são rápidas porque o diff é pequeno. Não há "dia de merge" porque o merge é contínuo. Equipes que praticam desenvolvimento baseado em trunk relatam frequências de deploy 4–8× maiores do que equipes usando branches de longa duração.

Os requisitos também são reais. O desenvolvimento baseado em trunk exige CI excelente (testes devem ser rápidos e confiáveis), infraestrutura robusta de feature flags (você precisa enviar código incompleto com segurança) e alta confiança entre engenheiros (sem gate de revisão significa que o autor assume total responsabilidade). Para uma equipe de 4 pessoas com CI forte e uma base de código compartilhada, geralmente é a forma mais rápida de trabalhar. Para uma equipe de 30 pessoas com cobertura de testes irregular, é uma receita para um branch main quebrado.

Isso é o GitHub Flow levado um passo adiante — menos branches, vidas mais curtas, mais dependência de flags do que de isolamento.

O GitHub Flow é o padrão correto para a maioria das equipes, e vale a pena entender o porquê. O modelo inteiro cabe em três regras: main está sempre pronta para deploy, toda mudança acontece em um branch de vida curta, e branches fazem merge para main via PRs revisados. É isso.

Não há branch develop, não há branch release, não há branch hotfix. Um branch por mudança, um PR por branch, um merge para main. Quando main recebe um novo merge, você pode fazer deploy — manualmente, automaticamente ou em um cronograma. A simplicidade é o recurso.

O GitHub Flow funciona porque corresponde a como a maioria das equipes de produto realmente entrega: continuamente, em pequenos incrementos, sem a sobrecarga de coordenar trens de release. Um feature branch vive por um dia ou dois, é revisado, faz merge e é enviado. Se quebrar algo, você reverte e corrige. O ciclo de feedback é curto.

Onde o GitHub Flow tem dificuldades é quando você precisa manter múltiplas versões de produção simultaneamente (você envia v2.3 mas precisa corrigir v2.1 para um cliente), ou quando seu processo de deploy é lento e caro (tornando "apenas reverta" irrealista). Esses cenários precisam de um modelo de ramificação mais estruturado — mas são a exceção, não a regra.

O GitFlow foi projetado para um mundo onde software era enviado em CDs — releases versionados, ciclos longos de QA, múltiplas versões suportadas em campo. Se esse é o seu mundo (aplicativos desktop, sistemas embarcados, software empresarial com suporte contratual de versões), a estrutura do GitFlow justifica sua complexidade.

O modelo adiciona vários branches de longa duração: develop (integração), release/* (estabilização), hotfix/* (correções emergenciais para produção) e main (estado de produção). Features ramificam de develop, releases bifurcam de develop quando uma versão está "feature-complete", e hotfixes ramificam diretamente de main.

Para equipes fazendo deploy de uma aplicação web — que é a maioria das equipes lendo este curso — o GitFlow é quase certamente excessivo. O branch develop adiciona uma camada de indireção entre seu trabalho e produção sem um benefício proporcional. Os branches de release fazem sentido apenas se você tem um gate formal de QA entre "código completo" e "enviado". Os branches de hotfix são desnecessários quando fazer deploy de uma correção leva minutos, não semanas.

O GitFlow não é ruim. Ele é projetado para um contexto específico. Se você não tem esse contexto (múltiplas versões suportadas, deploys lentos, gates formais de release), você está pagando o imposto da complexidade sem o benefício. Comece com o GitHub Flow. Você sempre pode adicionar estrutura depois se a situação exigir — mas raramente precisará.