No necesitás Gitflow. Necesitás integración continua de verdad.

El último gran merge que hiciste, ¿cuánto tiempo llevó resolverlo?

Si la respuesta es "más de 20 minutos" — o peor, "un día entero" — no es un problema de Git. Es un problema de estrategia de ramas.

El modelo mental equivocado

La mayoría de los equipos trata las ramas como mundos paralelos seguros. Abrís una rama, trabajás tranquilo, y cuando terminás la traés de vuelta al main.

El problema: mientras trabajás en tu universo paralelo, el resto del equipo sigue cambiando el universo principal. Y cuanto más tiempo pasa, más divergen esos mundos.

La ciencia ficción lo llama divergencia de líneas temporales. Los desarrolladores lo llaman merge conflict.

Gitflow: la arquitectura del conflicto

Gitflow fue propuesto por Vincent Driessen en 2010. Era el año en que todavía se usaba SVN, los deploys eran manuales, y las empresas lanzaban software cada tres meses.

El flujo tiene sentido en ese contexto: una rama develop, ramas de feature, ramas de release, hotfix branches. Todo muy ordenado sobre el papel.

El problema es que ese contexto ya no existe. Y Gitflow lleva ese modelo mental a un presente donde los equipos quieren deployar diariamente y los ciclos de feedback son de horas, no semanas.

Lo que Gitflow produce en la práctica:

• Ramas que viven días (a veces semanas)
• Merges que rompen builds de forma impredecible
• Integración que pasa "más tarde" y nunca es el momento correcto
• Un branch develop que está, en promedio, roto

El edificio que no podés habitar

Pensá en Gitflow como un edificio en construcción con la política de "nadie entra hasta que esté terminado".

El arquitecto diseña los planos. Los cimientos tardan dos meses. La estructura, otros dos. Cuando finalmente lo abren, descubren que las tomas de corriente no están donde nadie quería, y que el baño principal queda justo enfrente del ascensor.

Trunk-based development es otro modelo: el hotel abre desde el primer piso mientras sigue construyendo los superiores. Los huéspedes del primer piso dan feedback real. Si una habitación no está lista, la cerrás temporalmente — un feature flag — y la arreglás sin molestar a nadie.

Qué es trunk-based development

La idea central es simple: todos integran al main (trunk) frecuentemente — al menos una vez por día.

No hay ramas de larga vida. Si una rama existe más de uno o dos días, es una señal de alarma, no un estado normal de trabajo.

Las ramas cortas existen, pero su propósito es el review, no el aislamiento. El objetivo es integrar rápido y frecuentemente.

Google, Meta y Shopify trabajan con variantes de este modelo. Google, específicamente, tiene un solo repositorio donde miles de ingenieros integran al trunk todos los días. No porque sean extraordinarios — sino porque diseñaron sus prácticas para hacer eso posible.

El habilitador clave: los feature flags

La pregunta obvia es: "si integro código incompleto al main, ¿no lo rompo?"

Para eso existen los feature flags (o feature toggles).

Un feature flag es el equivalente técnico del cartel de "habitación en refacción" del hotel. El código de la nueva feature existe en producción, pero está desactivado para los usuarios reales. Lo activás cuando está listo — por ambiente, por usuario, por porcentaje del tráfico.

if (flags.newCheckout) {
  return <NewCheckoutFlow />
}
return <OldCheckoutFlow />

Esto te da ventajas concretas:

• Deploy sin release: podés deployar código sin activar la feature públicamente
• Rollback sin revertir commits: si algo sale mal, apagás el flag
• Testing en producción real: activás la feature para el 5% de los usuarios y medís el impacto antes de escalar

Herramientas como LaunchDarkly, Unleash o incluso una tabla en la base de datos hacen esto posible. No necesitás magia — necesitás disciplina.

El commit pequeño como práctica

Trunk-based development te obliga a pensar en commits pequeños e integrables. No "terminé la feature de checkout" — sino:

• Agrego schema de base de datos para carrito v2
• Agrego servicio de cálculo de totales (bajo feature flag, desactivado)
• Agrego UI del carrito v2 (oculta por flag)
• Activo flag para el equipo interno
• Activo flag para el 10% del tráfico

Cada uno de esos commits integra al trunk. Cada uno es deployable. Cada uno es revisable de forma aislada.

Este modelo te obliga a descomponer el trabajo en unidades que tienen sentido por sí solas — que es exactamente lo que querés, porque ese tipo de trabajo es el que escala.

CI/CD como la red de contención

En el circo, los acróbatas intentan trucos más arriesgados cuando hay red debajo. Los equipos integran más frecuentemente cuando hay CI que los respalda.

La integración continua no es solo "correr los tests automáticamente". Es el contrato social que dice: si el build está verde, el código puede integrarse. El pipeline tiene que ser rápido (bajo 10 minutos idealmente), confiable y definitivo.

Si el build se rompe, es urgente — no se deja en rojo mientras cada uno sigue trabajando. Un pipeline roto que nadie repara es peor que no tener uno: enseña que el feedback automático es ignorable.

Un pipeline lento tiene el mismo problema. Si tarda 40 minutos, nadie espera el resultado antes de seguir commiteando. Invertir en velocidad del pipeline no es optimización prematura — es la condición de posibilidad del modelo.

Cómo empezar desde donde estás

No necesitás migrar todo de una vez.

Primero, acortá las ramas que ya tenés. Si una rama tiene más de tres días, preguntate si podés integrar lo que ya existe (aunque incompleto) usando un feature flag. En la mayoría de los casos, sí podés.

Segundo, establecé el trunk como fuente de verdad. El main tiene que estar siempre en estado deployable. Si alguien lo rompe, es prioridad uno — no "lo veo cuando puedo".

Tercero, invertí en el pipeline. Un build de 40 minutos hace trunk-based development imposible. Necesitás feedback en menos de 10.

Cuarto, revisá el tamaño de los PRs. Un PR de 800 líneas es una señal de que el trabajo no está suficientemente descompuesto. El objetivo son PRs enfocados en una sola cosa, que se puedan revisar en menos de 15 minutos.

Quinto, introducí feature flags gradualmente. Empezá con una variable de entorno o una tabla simple. No necesitás una plataforma compleja para empezar.

El cambio que no es técnico

La resistencia a trunk-based development casi nunca es técnica. Es cultural.

"¿Si integro código sin terminar y algo sale mal?" — Exactamente lo que pasa ahora, pero más rápido de detectar y más fácil de diagnosticar, porque el delta de cambios es pequeño.

"¿Si todos integran al mismo lugar, cómo sabemos qué rompió quién?" — Lo sabés exactamente, porque cada commit es pequeño y atribuible.

El modelo de ramas largas crea una ilusión de seguridad. La rama se siente segura porque está aislada. Pero ese aislamiento es la causa del dolor — no la solución.

Trunk-based development es incómodo al principio porque te quita esa ilusión. Lo que pone en su lugar es algo mejor: visibilidad real del estado del sistema, en todo momento.

Y eso, con el tiempo, es lo que te deja dormir tranquilo la noche antes de un deploy.