Executando verificação de segurança...
2
obrenoalvim
1 min de leitura ·

Git flow vs trunk-based development: o que funciona para times pequenos?

Git flow foi o padrão por anos. Trunk-based development ganhou força com DevOps e CI/CD. Para um time de 3 a 10 pessoas, qual faz mais sentido?

Git flow

Branches de feature, develop, release, hotfix e main. Processo bem definido, fácil de entender para novatos.

Onde funciona: releases com data definida, código que precisa de QA antes de produção, times que não têm CI/CD maduro.

Onde quebra: merges longos, conflitos frequentes quando features ficam em branches por semanas, velocity real mais baixo do que parece.

Trunk-based development

Todo mundo commita direto na main (ou branches de vida curta, horas não dias). Deploy frequente, feature flags para esconder trabalho em progresso.

Onde funciona: times com CI/CD robusto, cultura de testes, deploys automatizados para produção.

Onde quebra: sem infraestrutura de testes, você vai quebrar produção. Feature flags mal gerenciadas viram dívida técnica.

O que eu uso

Para projetos solo ou times pequenos: branches de vida curta (1-3 dias) com merge para main. Sem release branch, sem develop separado. Deploy contínuo.

O Git flow completo para um time de 3 pessoas é overhead sem benefício proporcional.

A pergunta real

O seu processo de branching foi uma decisão consciente ou é o que veio com o projeto?

Carregando publicação patrocinada...
3
joaovictor6

Sinto que o git flow é uma armadilha. Traz uma falsa sensação de segurança e organização onde muitas empresas não técnicas focam em entrega continua e pouquíssimo foco em qualidade. O git flow torna o desenvolvimento mais dificil e o merge hell se torna rotineiro a longo prazo. Pelo menos foi essa a infelizmente experiência que tive das ultimas vezes que trabalhei em projetos com git flow.

A maioria das empresas não tem a organização que o git flow supostamente precisa. Sou 100% trunk based por aqui.

1
obrenoalvim
  • Autor
    Autor

Merge hell é exatamente onde o git flow começa a custar mais do que entrega. A premissa faz sentido num mundo com QA rigoroso e releases planejadas, mas a maioria dos times não opera assim. Você termina com features travadas em branch por semanas, conflito na hora do merge, e alguém resolvendo isso sob pressão. Trunk-based elimina o problema na raiz: integração contínua, main sempre deployável, feature flags pra controlar exposição. O ponto que mais vejo ser ignorado é que git flow exige disciplina de processo que time sem cultura técnica forte simplesmente não tem. Aí vira mais burocracia do que proteção.

3
joaovictor6

Um hobknob qualquer+ pipeline meia bomba + um lider técnico chato pra reforçar o uso de FF melhora MUITO a qualidade de vida da equipe. Pelo menos sinto isso na prática.

O Cemitério de FF é um problema mais fácil ao meu ver

1
obrenoalvim
  • Autor
    Autor

Concordo com a parte do líder técnico sendo chato: sem alguém empurrando de volta, a disciplina de remover flag depois do rollout some. O cemitério de FF ser mais fácil depende de ter isso claro desde o início. O que eu vi acontecer mais de uma vez é o time criar a flag, fazer o rollout, e ninguém agendar a limpeza porque "tá funcionando". Você usa alguma estratégia específica pra garantir a remoção, ou fica mais no enforcement manual mesmo?

1
joaovictor6

Atualmente fica no reforço do time. Reforço em todo onboarding a necessidade de declarar a criação de um release flag com um ticket e a mesma esta anexada ao ciclo de vida desse ticket com agendas recorrentes para a limpeza. Tida tarefa com RF tem um subticket de limpeza com um prazo de 7 dias úteis pós estabilização.

Porém no momento ti desenvolvento uma ferramenta bem simples pra gente conseguir automatizar esses lembretes