# O que é trunk based development e como funciona na prática

URL: https://formula.dog/pt/journal/o-que-e-trunk-based-development
Type: blog
Locale: pt
Published: 2026-09-12
Updated: 2026-09-13

---

> O que é trunk based development? Todos os devs fazem commit no trunk diariamente, branches vivem horas e feature flags escondem o trabalho incompleto dos usuários em produção.

O que e trunk based development? É um modelo de versionamento em que todos os desenvolvedores do time fazem commit no mesmo branch compartilhado -- chamado de trunk ou main -- pelo menos uma vez por dia. Sem branches de feature de longa duração. Sem `hotfix-v2-backup-final` esperando há três semanas. Branches curtas vivem horas, fazem merge rápido e são deletadas. A base de código fica continuamente pronta para entrar em produção. [O Google opera 35.000 desenvolvedores dessa forma](https://trunkbaseddevelopment.com/). Veja como funciona, quando faz sentido e quando não faz.

## O problema do "relatorio_v2_FINAL_use_this_one.xlsx" -- mas no código

Se você já abriu uma pasta compartilhada e encontrou `relatorio_v1.xlsx`, `relatorio_v2_FINAL.xlsx` e `relatorio_USE_ESTE_greg_edicoes.xlsx` lado a lado, você já entende a dor que o trunk based development tenta resolver.

Essa mesma situação acontece em bases de código quando os times usam branches de feature de longa duração. Alguém abre uma feature na semana um. O resto do time continua entregando. Na semana três, aquele branch está dezenas de commits atrás do main. Fazer o merge vira um projeto de fim de semana que ninguém quer assumir. Conflitos se acumulam. O desenvolvedor que escreveu o código já esqueceu por que metade dele existe. Isso é o "merge hell".

O Gitflow -- a alternativa mais ensinada -- tenta resolver isso com estrutura formal: branches separados para features, releases e hotfixes, cada um com um ciclo de vida definido. A estrutura parece limpa no papel. Na prática, os branches se acumulam como versões de planilha numa pasta compartilhada, e o dia da integração vira a semana da integração.

O trunk based development adota a posição oposta: pare de acumular dívida de integração. Faça commit no main. Hoje.

## Todo mundo faz commit no trunk. Todo dia. É assim que funciona.

A regra central é direta: todos os desenvolvedores enviam mudanças para o trunk compartilhado pelo menos uma vez a cada 24 horas. Sem exceções para "ainda não terminei" -- você faz commit do que tem e garante que o que tem não quebra o build.

Isso parece assustador até você entender os mecanismos que tornam isso seguro:

- 
**Branches de curta duração**: você ainda pode usar branches, mas eles vivem por horas, não por semanas. Um branch que dura mais de dois dias é um sinal de alerta que vale investigar.

- 
**Testes automatizados em cada commit**: seu pipeline de CI roda a suíte de testes imediatamente. Se algo quebra, você sabe em minutos, não no final de um sprint.

- 
**Feature flags**: funcionalidades incompletas ficam escondidas atrás de um toggle até estarem prontas para produção. Os usuários nunca veem trabalho inacabado, mesmo que ele já esteja no código de produção.

O resultado é uma base de código que está sempre pronta para produção -- não "pronta depois de fazermos o merge do branch de feature e rodarmos QA por uma semana", mas pronta agora se precisar. Essa é a promessa fundamental.

![Vários commits de código convergindo para um branch main no trunk based development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/f48347-inline1.webp)

## Branches de curta duração: meça em horas, não em semanas

No trunk based development, você não está proibido de usar branches. Você está proibido de usar branches longos.

Um branch que você abre às 9h, trabalha durante a manhã, recebe revisão de código depois do almoço e faz merge no main antes das 17h é exatamente o tipo certo. Dá aos colegas a chance de revisar o trabalho antes de chegar ao trunk. É pequeno o suficiente para entender em uma leitura. Conflitos, se houver, resolvem em minutos.

Um branch que vive três semanas enquanto um desenvolvedor constrói um sistema de autenticação inteiro em isolamento é o problema. Quando chega a hora do merge, o time gasta mais tempo resolvendo conflitos do que gastou construindo a feature.

O limite prático que a maioria dos times com TBD adota: se um branch não fez merge em dois dias, algo precisa mudar. Ou a feature é grande demais e precisa ser dividida em partes menores, ou ela precisa de uma feature flag para que o trabalho parcial entre com segurança.

Dividir o trabalho em partes menores é a disciplina central que o trunk based development realmente desenvolve. Em vez de "construir o dashboard inteiro", você entrega "adicionar a camada de dados", depois "adicionar o primeiro gráfico", depois "conectar os filtros". Cada parte faz merge no trunk, é testada e vai para produção de forma independente. A feature completa emerge de forma incremental ao longo de vários commits.

Parece mais lento. Na prática é mais rápido, porque você encontra os problemas enquanto o contexto ainda está fresco e a área de superfície ainda é pequena.

## Feature flags: como entregar trabalho incompleto sem quebrar nada

Feature flags -- também chamados de feature toggles -- são o mecanismo que torna o trunk based development prático quando uma feature não pode ser finalizada em um único branch de curta duração.

A ideia é simples: envolva a nova funcionalidade em uma condicional que só é ativada quando uma flag específica está ligada.

`if (featureFlags.newReportingDashboard) {
  renderNewDashboard();
} else {
  renderOldDashboard();
}`O novo código é implantado em produção. Ele simplesmente não roda para os usuários até que você vire o toggle. Isso significa:

- 
Desenvolvedores podem fazer commit de trabalho em progresso no trunk sem afetar ninguém

- 
QA pode testar a feature em produção ativando a flag para um usuário ou ambiente específico

- 
Um lançamento vira uma mudança de configuração, não um evento de deploy

- 
Se algo quebra, você desliga a flag sem precisar de rollback ou branch de hotfix

A infraestrutura de feature flags escala de uma simples variável de ambiente verificada na inicialização até plataformas dedicadas. Para um time que está começando, um arquivo de configuração ou variável por ambiente já é suficiente. O ponto é a capacidade, não a complexidade das ferramentas.

![Toggles de feature flags controlando o deploy de código no trunk based development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/d557e7-inline2.webp)

## Quando o trunk based development não é a escolha certa

Vale dizer diretamente: o trunk based development não é universalmente melhor. Ele se encaixa em contextos específicos.

Evite se:

**Seu pipeline de CI/CD não está pronto.** Trunk based development sem testes automatizados em cada commit não é uma estratégia de branching -- é uma base de código quebrada acumulando velocidade. A infraestrutura de testes precisa estar em funcionamento antes que o modelo de branching possa funcionar.

**O time não consegue fazer commit frequente por natureza.** Times distribuídos onde os contribuidores trabalham de forma assíncrona em fusos horários diferentes, ou projetos de código aberto onde os contribuidores enviam lotes esporádicos, vão encontrar dificuldade em manter a cadência de commit diário.

**Você está em um ambiente regulamentado com janelas de release obrigatórias.** Alguns setores exigem aprovação externa, longos ciclos de QA e trilhas de auditoria formais por branch de release. As branches estruturadas do Gitflow se encaixam melhor nesse tipo de fluxo de trabalho.

**A disciplina do time ainda não está consolidada.** O trunk based development exige que cada commit no main ou passe em todos os testes ou seja corrigido imediatamente. Se o time tolera builds quebrados, o trunk compartilhado vira o problema compartilhado de todos.

O Gitflow é uma escolha razoável para times com calendários de release trimestrais, múltiplas features em desenvolvimento simultâneo por squads separados, ou requisitos de conformidade que demandam isolamento no nível de branch. A questão é adequação honesta, não qual abordagem vence no princípio.

## Como migrar do Gitflow para o TBD sem crise

Se o seu time usa Gitflow e quer experimentar o trunk based development, a migração não precisa ser uma transição abrupta.

Comece parando de criar novos branches de longa duração. Features iniciadas após a decisão recebem branches de curta duração. Features já em progresso em branches longos terminam sob o modelo antigo. As duas abordagens coexistem temporariamente.

Antes de fazer commit de trabalho inacabado no trunk, você precisa ter feature flags no lugar. Configurar mesmo um sistema básico de feature flags é o pré-requisito para todo o resto. Sem ele, trunk based development significa entregar UI incompleta para os usuários em produção.

Então imponha CI no branch main: testes automatizados rodam em cada push, testes com falha bloqueiam o merge, e ninguém faz merge sem um build passando. Esta é a parte inegociável.

Por fim, defina a regra dos dois dias explicitamente: qualquer branch com mais de dois dias recebe uma conversa sobre o que fazer com ele. Divida a feature em partes menores, adicione uma flag, ou entregue o que já está pronto. Torne isso visível no processo de pull request.

O ajuste desconfortável que a maioria dos times enfrenta: aceitar que "parcialmente completo" é uma coisa válida para fazer commit, desde que esteja escondido atrás de uma flag e não quebre os testes existentes.

## O que os dados do relatório DORA dizem sobre velocidade de entrega

Os relatórios DevOps Research and Assessment (DORA) são o equivalente mais próximo que o desenvolvimento de software tem de pesquisa empírica em larga escala sobre práticas de times. O relatório DORA de 2021 descobriu que times de alto desempenho têm 2,3 vezes mais chances de usar trunk based development em comparação com times de menor desempenho.

Os melhores times no framework DORA fazem deploy várias vezes por dia, com lead times do commit até a produção medidos em horas, não em semanas. O trunk based development se correlaciona consistentemente com esses resultados.

O aviso importante: correlação não é causalidade. Times de alto desempenho adotam o trunk based development porque já investiram na disciplina subjacente -- testes automatizados, infraestrutura sólida de CI/CD, engenheiros que escrevem mudanças pequenas e focadas. Essas bases vêm primeiro. O trunk based development é o modelo de branching que se encaixa nesse contexto, não a coisa que o cria.

Biscuit entende isso rápido: um bom retriever não tenta carregar três bolas de uma vez. Um commit, uma revisão, um merge. Bom garoto.

![Visualização do pipeline de deploy contínuo mostrando código fluindo dos commits para a produção](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/6305c9-inline3.webp)

Se o seu time gasta tempo significativo a cada sprint em conflitos de merge, atrasa releases porque "o branch de feature não está pronto", ou tem branches abertos há tanto tempo que ninguém se lembra para que serviam -- o trunk based development vale uma avaliação séria.

A cadência de commit diário é exigente. A infraestrutura de feature flags precisa de configuração. A mudança cultural leva algumas semanas. Mas o resultado -- uma base de código sempre pronta para produção, conflitos de merge medidos em linhas e não em arquivos, e releases que são rotineiras em vez de crises -- é uma melhoria concreta na forma como o time trabalha.

Comece pequeno: um time, um sprint, CI rodando em cada push, feature flags no lugar. Veja o que muda em quatro semanas.

## FAQ

### O que é trunk based development em termos simples?

É um modelo de versionamento em que todos os desenvolvedores fazem commit no mesmo branch principal -- o trunk ou main -- pelo menos uma vez por dia. Sem branches de feature de longa duração. A base de código fica sempre pronta para produção.

### Qual a diferença entre trunk based development e Gitflow?

No Gitflow, existem branches formais e separados para features, releases e hotfixes, com ciclos de vida definidos. No TBD, todos fazem commit no trunk com frequência, usando branches de curta duração -- horas, não semanas -- e feature flags para esconder trabalho incompleto.

### O que são feature flags e por que são essenciais no TBD?

Feature flags são condicionais que ativam ou desativam funcionalidades em produção sem precisar de um novo deploy. No TBD, elas permitem que o trabalho em progresso entre no trunk sem afetar os usuários até que esteja completamente pronto.

### Quanto tempo um branch pode viver no trunk based development?

A regra prática é: no máximo dois dias. Um branch que não fez merge em 48 horas precisa de atenção. Ou a feature é grande demais e deve ser dividida em partes menores, ou precisa de uma feature flag para o trabalho parcial entrar com segurança.

### O trunk based development funciona para times remotos e distribuídos?

Funciona, mas é mais desafiador. Times assíncronos em fusos horários muito diferentes têm dificuldade em manter a cadência de commit diário. Nesses casos, o Gitflow ou abordagens híbridas podem ser mais adequados ao ritmo do time.

### Quais são os pré-requisitos para adotar trunk based development?

O mínimo indispensável: um pipeline de CI/CD configurado que rode testes em cada push, algum sistema de feature flags -- mesmo básico -- e a disciplina do time de corrigir builds quebrados imediatamente. Sem CI, o TBD não funciona.

### O que os dados do DORA dizem sobre trunk based development?

O relatório DORA 2021 mostra que times de alto desempenho têm 2,3 vezes mais chances de usar TBD. Mas a correlação não é causalidade: times que já têm boa disciplina de testes e CI/CD tendem a adotar TBD, não o contrário.