GitFlow

main, develop, feature, release y hotfix. Pensado para software versionado con releases planificados.

Contexto

Publicado por Vincent Driessen en 2010, para software con versiones numeradas y ciclos de release: apps de escritorio, mobile, librerías, productos on-premise. Su propio autor aclaró años después que no es lo ideal para aplicaciones web con entrega continua.

Solución

Dos ramas permanentes y tres tipos de ramas de apoyo:

Rama	Origen	Se mergea a	Para qué
`main`	—	—	Solo código publicado, cada commit es un release con tag
`develop`	`main`	—	Integración de lo que va para el próximo release
`feature/*`	`develop`	`develop`	Una funcionalidad
`release/*`	`develop`	`main` y `develop`	Estabilizar y versionar un release
`hotfix/*`	`main`	`main` y `develop`	Corregir producción de urgencia

CSHARP

main     ──●─────────────────●───────────●──▶  (tags v1.0, v1.1, v1.1.1)
            \               / \         /
release      \       ●──●──●   \       /
              \     /           \     /
develop  ──●───●──●──●────●──●───●──●──●──▶
              \  /      \  /
feature        ●●        ●●
hotfix                      ●──────────●   (desde main)

#Costos reales

Dos ramas largas (main y develop) que hay que mantener sincronizadas.
Merges grandes y conflictos al cerrar un release.
Los bugs se encuentran tarde: el código tarda en llegar a main y a producción.
Con deploy continuo el modelo estorba: develop y main son casi lo mismo.

Cuándo NO aplicarlo

Aplicaciones web/SaaS que despliegan varias veces al día.
Equipos chicos sin versiones soportadas en paralelo: es overhead sin retorno.
Si querés Trunk-Based o integración continua real: GitFlow va en contra.

Tradeoffs

Pro	Contra
Roles de rama claros y explícitos	Mucha ceremonia y ramas de larga vida
Soporta varias versiones y hotfixes ordenados	Merges difíciles, integración tardía
Encaja con releases planificados y QA por etapas	Frena la entrega continua

#git #branching #gitflow #release