3

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.

Carregando publicação patrocinada...
1

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

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

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?

3

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

1

Subticket de limpeza com prazo definido é o que separa time que tem processo de time que tem intenção. Sem isso, release flag vira legado em silêncio — todo mundo sabe que precisa limpar, ninguém coloca no calendário.

Curioso pra ver a ferramenta de lembretes. Parece um daqueles problemas que ficam no 'dá pra fazer manualmente' até o dia que você conta 40 flags ativas no código.