Trunk-Based Development

Todo el equipo integra en una única rama (trunk/main) con ramas de vida muy corta y feature flags.

Contexto

Equipos con integración y entrega continuas que quieren minimizar el costo de integrar. Es el modelo que más se asocia con equipos de alto rendimiento en las métricas DORA (frecuencia de deploy y lead time).

Problema

Las ramas de larga vida divergen. Cuanto más tarde se integran, más conflictos, más riesgo y más trabajo "oculto" que nadie ve hasta el final.

Solución
  • Existe una sola rama de integración: main (el trunk).
  • Cada persona hace commits directos al trunk o usa ramas de vida corta (menos de uno o dos días).
  • El trunk siempre compila y pasa los tests: el CI corre en cada push.
  • El trabajo incompleto se esconde detrás de Feature Flags, no en una rama.
  • Los cambios grandes se hacen con branch by abstraction: se introduce una abstracción, se migra de a poco y se retira la implementación vieja.

#Flujo

CSHARP 
main ──●──●──●──●──●──●──●──●──▶   (siempre desplegable)
        \  /    \  /
         ●       ●     ← ramas de horas, no de semanas
BASH 
git switch -c fix/rounding-error
# ... cambio chico, tests locales
git push -u origin fix/rounding-error
# PR corto, review rápido, merge hoy mismo
git switch main && git pull --ff-only

#Releases

  • Desde el trunk: cada commit verde es candidato a producción (deploy continuo).
  • Rama de release corta: si necesitás estabilizar, cortás release/1.4 desde el trunk; los fixes se hacen en el trunk primero y se cherry-pickean a la rama de release.

#Qué necesitás para que funcione

  • CI rápido (minutos, no horas) y tests automatizados confiables.
  • Feature flags y una forma de limpiarlos cuando dejan de usarse.
  • Revisiones de código rápidas (PRs chicos) o pair/mob programming.
  • Cultura de "romper el build es la urgencia número uno".
Cuándo NO aplicarlo
  • Sin tests automatizados ni CI confiable: vas a romper main seguido.
  • Equipos con muchas personas nuevas o sin experiencia, sin revisión rápida.
  • Software con varias versiones soportadas en paralelo: mejor ramas de release (ver GitFlow).
Tradeoffs
Pro Contra
Merges triviales, casi sin conflictos Exige CI y tests sólidos
Feedback y deploys muy frecuentes Requiere disciplina con feature flags
Menos overhead de gestión de ramas Cultura: cuesta si el equipo viene de ramas largas

#git #branching #ci #trunk-based