Estratégias de Source Code Management elevam seu time
E por que Trunk-Based quase sempre é o norte
Tem um tipo de “maturidade” que aparece rapidinho quando você olha as métricas do time: lead time alto, deploy raro, PR gigante, merge doloroso, hotfix na sexta-feira, e um cemitério de branches que ninguém sabe se ainda vive.
A parte interessante é que, muitas vezes, isso não é “falta de talento” — é falta de um sistema de entrega que favoreça fluxo. E um dos componentes mais subestimados desse sistema é a estratégia de Source Code Management (gestão do código / branching model).
Se você quer evoluir a maturidade do time e melhorar métricas, vale olhar para o Git do mesmo jeito que você olha para arquitetura: como um mecanismo que reduz risco e aumenta previsibilidade.
Por que SCM impacta diretamente métricas?
Quando falamos de maturidade, normalmente caímos em métricas (DORA é um ótimo começo):
Lead Time for Changes: quanto tempo do commit até produção
Deployment Frequency: com que frequência você entrega
Change Failure Rate: quanto quebra ao entregar
MTTR: quanto tempo para recuperar quando quebra
A estratégia de branches influencia isso porque ela define:
tamanho do lote (batch size): PR grande aumenta risco e tempo
tempo de integração: integração tardia = conflitos + retrabalho
capacidade de liberar com segurança: sem medo de “subir incompleto”
custo de coordenação: mais branches long-lived = mais cerimônia
Em outras palavras: o Git vira o “trânsito” do seu delivery. Se ele trava, o fluxo trava.
Trunk-Based Development (TBD): o que ele resolve de verdade
Trunk-Based é simples na ideia e exigente na disciplina:
existe uma “linha principal” (main/trunk) sempre saudável
o time integra mudanças o tempo todo
mudanças são pequenas, revisadas e validadas por CI
funcionalidades incompletas são protegidas por feature toggles (ou técnicas como branch by abstraction)
Prós do Trunk-Based
Menos conflito e menos inferno de merge: integração contínua reduz divergência.
Batch menor = menos risco: PR pequeno é mais fácil de revisar e testar.
Release mais previsível: trunk pronto para liberar o tempo todo.
Melhora natural de métricas: lead time cai, frequência de deploy sobe, MTTR tende a cair por mudanças menores.
Excelente para microserviços e times pequenos: menos gente mexendo no mesmo repo, mais fluidez, menos coordenação.
Contras (e o “preço” do modelo)
Pede maturidade de engenharia: CI confiável, testes automáticos, trunk “sempre verde”.
Exige boa governança de feature toggles: sem disciplina, vira dívida permanente.
Requer cultura de PR pequeno: “um PR por semana” mata o modelo.
Pode assustar em contextos com pouca automação: se seu pipeline é frágil, trunk vira sofrimento.
O Trunk-Based não “funciona apesar” de disciplina. Ele funciona por causa dela.
GitFlow: quando ajuda e quando vira âncora
GitFlow nasceu num contexto em que releases eram mais “pacotes”, menos contínuos. Ele geralmente traz branches long-lived (develop, release, hotfix, etc.).
Prós do GitFlow
Bom para releases versionadas e ciclos mais longos (produto com releases “fechadas”).
Separação clara de estágios (dev vs release vs hotfix).
Funciona em times que ainda não têm CI/CD forte, porque tenta “organizar” via processo.
Contras (os clássicos)
Integração tardia = conflito e retrabalho.
Branch de release vira mini-projeto: cherry-pick, backmerge, correções duplicadas.
Aumenta custo de coordenação (especialmente com microserviços).
Piora batch size: features acumulam e explodem na hora do merge.
Pode mascarar problemas: o processo vira muleta para falta de automação.
GitFlow não é “errado” — mas em ambientes modernos (CI/CD + entregas frequentes), ele tende a reduzir fluxo.
Outros modelos famosos (e onde entram)
GitHub Flow (variação popular)
branch curta por PR + main sempre deployável
Prós: simples, próximo do Trunk-Based.
Contras: se branch começa a durar muito, vira “GitFlow disfarçado”.
Release Flow / Release Branching (híbrido comum em produtos)
main + branch de release curta quando necessário (suporte, correções em produção, versões)
Prós: bom para quem precisa manter versões.
Contras: se a release branch vira longa e cheia de feature, você voltou ao problema.
Environment Branching (dev/hml/prod como branches)
geralmente um anti-pattern moderno
Prós: dá sensação de controle.
Contras: mistura “estado de ambiente” com “histórico de código”, vira caos rápido.
A escolha certa depende do contexto: uma matriz prática
Pensa na decisão como um trade-off entre fluxo e controle por processo.
Regras simples que funcionam bem
Se você quer entregar com frequência (e medir isso) → mire em Trunk-Based / GitHub Flow.
Se você mantém múltiplas versões em produção → Release Flow costuma ser o melhor “meio termo”.
Se seu time depende de branches longas para “se sentir seguro” → o problema provavelmente é automação/qualidade, não o modelo.
Feature toggles: o “segredo” para trunk com segurança (e sem bagunça)
Temos um ponto-chave: Trunk-Based fica excelente quando você confia em:
feature toggles bem desenhadas
revisão de código focada
arquitetura que facilita ligar/desligar
gestão para remover toggles depois
Aqui vai um mini-kit de governança que evita virar dívida:
Toda toggle tem: dono + motivo + data de expiração
Toggle não é permissão (isso é outra coisa: feature flags vs authorization)
Tipos claros:
release toggles (curto prazo)
ops toggles / kill switch (segurança operacional)
experiment toggles (A/B)
Checklist na PR:
“Tem plano de remoção?”
“Tem observabilidade para quando estiver ON?”
Rotina de limpeza (quinzenal/mensal): “toggle debt review”
Toggle sem data de remoção é só “branch longa” com outro nome.
Como migrar para Trunk-Based sem trauma
Se hoje vocês estão no GitFlow (ou algo parecido), dá para evoluir por etapas:
Reduza o tempo de vida das branches (meta: horas/dias, não semanas)
PRs menores (meta: revisão em < 24h)
CI como gate (build + testes + linters obrigatórios)
Trunk sempre verde (se quebrou, prioridade é consertar)
Comece com toggles para features grandes
Se precisar, use release branch curta (não reintroduza develop infinito)
O objetivo é tornar “integrar” um hábito — não um evento.
Por que Trunk-Based vira o norte em times maduros
Em arquitetura distribuída, microserviços e times pequenos, o custo de coordenação explode rápido. O Trunk-Based é um “atalho” para maturidade porque ele força bons comportamentos:
lote pequeno
integração contínua
automação
disciplina de qualidade
delivery como fluxo
Ele não é só um jeito de commitar. É uma forma de operar.
Se você quer melhorar métricas, a pergunta não é “qual modelo é mais famoso?”. É:
qual modelo reduz atrito de integração e aumenta minha capacidade de entregar com segurança?
Na maioria dos casos modernos, essa resposta aponta para o trunk.