Git no impone ningún flujo de trabajo particular; solo provee las primitivas (ramas baratas, fusiones, rebase). Cada equipo elige una convención. Las más comunes:
Cada nueva funcionalidad o corrección se desarrolla en su propia rama, creada a partir de la rama principal, y se fusiona de vuelta (normalmente vía revisión de código) al terminar. Simple y flexible; funciona bien con equipos de cualquier tamaño.
Las ramas viven muy poco tiempo (horas o pocos días) y se fusionan a la rama principal (trunk) con mucha frecuencia, apoyándose en feature flags para ocultar funcionalidad incompleta en producción en vez de mantenerla aislada en una rama larga. Reduce el riesgo de fusiones conflictivas grandes.
Un modelo más estructurado con ramas de larga duración con roles
fijos: main (solo versiones publicadas), develop
(integración continua), ramas de feature, release y
hotfix. Da mucha estructura pero agrega complejidad;
funciona mejor en proyectos con ciclos de publicación formales y
espaciados, y ha caído en desuso en equipos que despliegan
continuamente.
No hay un modelo universalmente "correcto": la elección depende de la frecuencia de publicación, el tamaño del equipo y qué tan formal necesita ser el proceso de revisión.