Desenvolvimento baseado em trunk

Visão geral

O desenvolvimento baseado em trunk é um fluxo de trabalho em que cada desenvolvedor integra em um único branch compartilhado — o trunk (geralmente main) — pelo menos uma vez por dia. Os branches, quando usados, são pequenos e existem por horas, não semanas. É o fluxo de trabalho por trás da verdadeira integração contínua e é favorecido por equipes que fazem deploy com frequência.

A ideia central

Quanto mais o seu código diverge do de todos os outros, mais difícil fica a integração. O custo de um merge cresce com o tamanho da divergência: um branch que existe há duas semanas acumula mais conflitos, e esses conflitos são mais difíceis de resolver porque muita coisa mudou dos dois lados.

O desenvolvimento baseado em trunk ataca esse problema diretamente, mantendo a diferença pequena. Você integra ao trunk constantemente — pelo menos uma vez por dia — de modo que qualquer conflito é pequeno e detectado enquanto a mudança ainda está fresca na sua memória. Não há um branch develop de longa duração nem merges explosivos. O trunk está sempre em um estado que pode ser lançado.

Existem dois estilos comuns:

• Commit direto no trunk. Equipes pequenas fazem commit diretamente no main, confiando em verificações pré-push e revisão em pares. Essa é a forma mais pura.
• Branches de curta duração. Equipes maiores criam um branch para cada mudança, abrem um pull request e fazem o merge em um ou dois dias. O branch existe apenas o tempo suficiente para executar o CI e obter uma revisão rápida.

Um ciclo típico de branch de curta duração se parece com este:

git switch main          # start from the trunk
git pull                 # get everyone else's latest work
git switch -c quick-fix  # tiny, focused branch
# ...a few hours of work...
git switch main
git pull                 # pull again — others have merged since you branched
git merge quick-fix      # fast, because divergence is small
git push                 # back on the trunk within the same day

O git pull repetido é intencional: fazer pull antes de mesclar mantém seu branch próximo ao trunk para que o merge permaneça trivial. Se você preferir um histórico linear, algumas equipes fazem rebase do branch de curta duração sobre o main em vez de mesclar. Consulte o fluxo de trabalho de feature branch para entender em detalhes a mecânica de branch e pull request.

Feature flags: como enviar trabalho inacabado com segurança

Se todos fazem merge no trunk diariamente, como lidar com uma funcionalidade que leva duas semanas? Você não pode manter um branch ativo por tanto tempo sem comprometer todo o propósito. A resposta é uma feature flag — uma chave em tempo de execução que decide se o novo código realmente é executado. Você faz merge do código incompleto, mas o mantém desativado:

const featureFlags = { newCheckout: false };

function checkout() {
  if (featureFlags.newCheckout) {
    return "new checkout";
  }
  return "old checkout";
}

console.log(checkout()); // old checkout — flag is off in production

O novo código chega à produção oculto por trás da flag. Quando estiver pronto, você muda newCheckout para true — sem necessidade de novo deploy. Isso separa o deploy do código do lançamento de uma funcionalidade, o que permite que trabalhos inacabados vivam com segurança no trunk.

Algumas regras práticas evitam que as flags se tornem uma bagunça:

• Padrão desativado. O novo código permanece oculto até que você o ative deliberadamente, muitas vezes para usuários internos primeiro.
• Trate as flags como temporárias. Uma vez que uma funcionalidade esteja totalmente lançada, remova a flag e o ramo else morto — flags desatualizadas se acumulam rapidamente e tornam o código difícil de ler.
• Teste os dois caminhos. O CI deve executar o código com a flag ativada e desativada, já que ambos chegam à produção.

O que ela exige

O desenvolvimento baseado em trunk é rápido, mas não é desleixado — ele só funciona com práticas de suporte sólidas:

• CI robusto: cada push executa um conjunto de testes automatizados, porque um trunk quebrado bloqueia toda a equipe.
• Commits pequenos e frequentes: grandes mudanças são divididas em etapas seguras e incrementais.
• Feature flags para qualquer coisa que não possa ser concluída em um único branch de curta duração.
• Revisão de código rápida, muitas vezes via pull requests pequenos que são mesclados em horas.

Se a revisão leva dias, os branches ficam ativos por dias, e você não está mais fazendo desenvolvimento baseado em trunk. As práticas de suporte não são extras opcionais — são o que torna a velocidade segura.

Lançamentos a partir do trunk

Como o trunk está sempre em um estado que pode ser lançado, os releases são simples. Dois padrões dominam:

• Lançamento a partir do topo. Faça deploy do main diretamente, com a frequência que desejar. Marque cada release com uma tag para identificar exatamente o que foi enviado:

  git switch main
  git pull
  git tag -a v1.4.0 -m "Release 1.4.0"
  git push origin v1.4.0

  Copiar

• Criar um branch de release. Para produtos que disponibilizam versões específicas, crie um branch de release de curta duração a partir do trunk, estabilize-o e aplique a tag a partir daí. As correções são feitas primeiro no trunk e depois aplicadas via cherry-pick no branch de release — nunca ao contrário, para que o trunk permaneça a fonte da verdade.

Ambas mantêm o trunk saudável: ele é sempre o código mais recente e funcional, e os releases são snapshots tirados a partir dele.

Trunk-based vs Gitflow

O Gitflow é otimizado para releases controlados e versionados com muitos tipos de branch. O desenvolvimento baseado em trunk é otimizado para velocidade e entrega contínua com essencialmente um único branch. Se você faz deploy várias vezes por dia, o trunk-based é adequado; se você lança releases versionados em um cronograma, a estrutura do Gitflow pode ser mais útil.

Quando usar

Opte pelo desenvolvimento baseado em trunk quando você faz deploy com frequência, tem testes automatizados confiáveis e consegue manter a revisão de código rápida. Ele recompensa equipes que valorizam ciclos curtos de feedback em vez de processos pesados. Se seus testes são instáveis, a revisão é lenta ou você precisa agrupar trabalho em releases agendados, o fluxo de trabalho de feature branch ou o Gitflow será menos trabalhoso. Para um panorama de todos os modelos comuns, consulte a visão geral dos fluxos de trabalho Git.

Prática