Desarrollo basado en trunk

Descripción general

El desarrollo basado en trunk es un flujo de trabajo donde cada desarrollador integra en una única rama compartida — el trunk (normalmente main) — al menos una vez al día. Las ramas, si se usan, son pequeñas y duran horas, no semanas. Es el flujo de trabajo detrás de la verdadera integración continua y es el favorito de los equipos que hacen despliegues frecuentes.

La idea central

Cuanto más se aleja tu código del de los demás, más difícil se vuelve la integración. El coste de un merge crece con el tamaño de la divergencia: una rama que ha vivido dos semanas acumula más conflictos, y esos conflictos son más difíciles de resolver porque ha cambiado mucho en ambos lados.

El desarrollo basado en trunk ataca ese problema directamente manteniendo la brecha pequeña. Integras en el trunk constantemente — al menos una vez al día — de modo que cualquier conflicto es pequeño y se detecta mientras el cambio aún está fresco en tu mente. No hay una rama develop de larga duración ni merges masivos. El trunk siempre está en un estado listo para publicar.

Hay dos estilos comunes:

• Hacer commits directamente al trunk. Los equipos pequeños hacen commits directamente a main, apoyándose en comprobaciones pre-push y revisión en pares. Esta es la forma más pura.
• Ramas de corta duración. Los equipos más grandes crean una rama por cada cambio, abren un pull request y hacen el merge en un día o dos. La rama existe solo el tiempo necesario para ejecutar la CI y recibir una revisión rápida.

Un ciclo típico con ramas de corta duración tiene este aspecto:

git switch main          # start from the trunk
git pull                 # get everyone else's latest work
git switch -c quick-fix  # tiny, focused branch
# ...a few hours of work...
git switch main
git pull                 # pull again — others have merged since you branched
git merge quick-fix      # fast, because divergence is small
git push                 # back on the trunk within the same day

El git pull repetido es deliberado: hacer pull antes del merge mantiene tu rama cerca del trunk para que el merge sea trivial. Si prefieres un historial lineal, algunos equipos hacen rebase de la rama de corta duración sobre main en lugar de hacer merge. Consulta el flujo de trabajo de ramas de funcionalidad para ver los detalles de los mecanismos de rama y pull request.

Feature flags: publicar trabajo inacabado de forma segura

Si todos hacen merge al trunk a diario, ¿cómo gestionas una funcionalidad que tarda dos semanas? No puedes mantener una rama activa tanto tiempo sin anular el objetivo. La solución es un feature flag — un interruptor en tiempo de ejecución que decide si el nuevo código realmente se ejecuta. Haces merge del código incompleto, pero lo mantienes desactivado:

const featureFlags = { newCheckout: false };

function checkout() {
  if (featureFlags.newCheckout) {
    return "new checkout";
  }
  return "old checkout";
}

console.log(checkout()); // old checkout — flag is off in production

El nuevo código llega a producción oculto detrás del flag. Cuando está listo, cambias newCheckout a true — sin necesidad de redesplegar. Esto desacopla el despliegue del código de la publicación de una funcionalidad, que es lo que permite que el trabajo inacabado viva de forma segura en el trunk.

Unas pocas reglas prácticas evitan que los flags se conviertan en un caos:

• Desactivado por defecto. El nuevo código permanece oculto hasta que lo activas deliberadamente, a menudo primero para usuarios internos.
• Trata los flags como temporales. Una vez que una funcionalidad está completamente lanzada, elimina el flag y la rama else muerta — los flags obsoletos se acumulan rápidamente y dificultan la lectura del código.
• Prueba ambas rutas. La CI debe ejecutar el código con el flag activado y desactivado, ya que ambos llegan a producción.

Lo que exige

El desarrollo basado en trunk es rápido, pero no es descuidado — solo funciona con prácticas de apoyo sólidas:

• CI robusta: cada push ejecuta una suite de pruebas automatizadas, porque un trunk roto bloquea a todo el equipo.
• Commits pequeños y frecuentes: los cambios grandes se dividen en pasos seguros e incrementales.
• Feature flags para todo lo que no pueda terminarse en una única rama de corta duración.
• Revisión de código rápida, a menudo mediante pull requests pequeños que se mergean en horas.

Si la revisión tarda días, las ramas duran días y ya no estás haciendo desarrollo basado en trunk. Las prácticas de apoyo no son extras opcionales — son las que hacen que la velocidad sea segura.

Publicar desde el trunk

Como el trunk siempre está listo para publicar, los lanzamientos son sencillos. Predominan dos patrones:

• Publicar desde la punta. Desplegar main directamente, con la frecuencia que quieras. Marca cada lanzamiento con un tag para identificar exactamente qué se publicó:

  git switch main
  git pull
  git tag -a v1.4.0 -m "Release 1.4.0"
  git push origin v1.4.0

  Copiar

• Crear una rama de lanzamiento. Para productos que publican versiones numeradas, crea una rama de lanzamiento de corta duración desde el trunk, estabilízala y crea el tag desde ahí. Las correcciones se hacen primero en el trunk y luego se aplican con cherry-pick en la rama de lanzamiento — nunca al revés, para que el trunk siga siendo la fuente de verdad.

Ambos mantienen el trunk saludable: siempre contiene el último código válido y los lanzamientos son instantáneas tomadas de él.

Trunk-based vs Gitflow

Gitflow está optimizado para lanzamientos versionados y controlados con muchos tipos de ramas. El desarrollo basado en trunk está optimizado para la velocidad y la entrega continua con esencialmente una sola rama. Si despliegas varias veces al día, el trunk-based encaja; si publicas versiones numeradas según un calendario, la estructura de Gitflow puede servir mejor.

Cuándo usarlo

Opta por el desarrollo basado en trunk cuando despliegues frecuentemente, tengas pruebas automatizadas fiables y puedas mantener la revisión de código rápida. Premia a los equipos que valoran los ciclos de retroalimentación cortos por encima de procesos complejos. Si tus pruebas son inestables, la revisión es lenta o debes agrupar el trabajo en lanzamientos programados, el flujo de trabajo de ramas de funcionalidad o Gitflow serán menos problemáticos. Para un recorrido por todos los modelos comunes, consulta la descripción general de los flujos de trabajo de Git.

Práctica