7. Git Flow: orden cuando el equipo crece

¿Qué es Git Flow?

Ya sabés usar ramas y Pull Requests. Git Flow es un modelo de ramificación propuesto por Vincent Driessen en 2010: no es un comando de Git, sino una convención de nombres y reglas sobre qué rama existe para qué propósito. Muchos equipos lo adoptan (o lo adaptan) para que todo el mundo hable el mismo idioma: dónde vive el código estable, dónde se integran features y cómo salen los parches urgentes.

Si tu proyecto es pequeño, a veces solo usás main y ramas cortas; Git Flow entra con fuerza cuando necesitás separar claramente "lo que ya salió al mundo" de "lo que estamos armando para la próxima versión", o cuando el equipo tiene roles definidos y procesos de aprobación.

Las dos ramas largas

En Git Flow hay dos ramas que nunca se borran — son la columna vertebral del modelo:

• main (o master): refleja producción. Solo recibe merges desde release o hotfix. Cada vez que llega un merge se etiqueta con el número de versión (v2.4.0). Nadie hace commits directos aquí.
• develop: la línea de integración del próximo release. Las features terminadas aterrizan aquí. Cuando el equipo decide que develop está lista para salir a producción, se abre una rama release.

Ramas de apoyo (con prefijos)

Estas ramas son temporales: nacen con un propósito y se fusionan y borran al terminar.

• feature/nombre: sale de develop, implementa una historia de usuario o tarea, y vuelve a develop vía Pull Request. Ejemplo: feature/login-oauth o feature/carrito-compras. Nunca toca main directamente.
• release/x.y.z: se corta desde develop cuando la versión está casi lista. En esa rama solo entran correcciones de último momento (bump de versión, ajuste de changelog, un bug de borde). Al terminar, se fusiona a main y también de vuelta a develop, y se etiqueta el commit en main (v2.4.0).
• hotfix/x.y.z: parche urgente en producción. Part de main, se corrige el bug, se fusiona a main (nuevo tag) y también a develop para que el arreglo no se pierda en la línea de desarrollo activa.

Ejemplo real: el equipo "Café API"

Imaginá la empresa "Café API", con un backend en Node y una app web en React. Despliegan cada vez que etiquetan una versión en main. El equipo tiene roles claros:

• Lucía (tech lead): define prioridades, revisa PRs críticos y aprueba los merges a main — desde release o hotfix.
• Mateo y Sofía (desarrollo): trabajan en historias del sprint en feature/pagos-stripe y feature/notificaciones-push, abriendo PR hacia develop.
• Diego (QA): prueba el entorno de staging que refleja develop; cuando se congela una versión, valida la rama release/2.4.0.
• Valentina (DevOps): el pipeline despliega main a producción y mantiene el changelog alineado con los tags.

En resumen: features aterrizan en develop; versiones estables salen por release → main; urgencias en prod van por hotfix. El equipo comparte un lenguaje de ramas sin mezclar "código en progreso" con "código desplegado".

Cómo encajan las Pull Requests

Las Pull Requests siguen siendo el mecanismo de revisión de código: una feature termina en un PR hacia develop; un hotfix en un PR hacia main. Git Flow define qué ramas existen y qué tocan; el PR define cómo revisamos y aprobamos cada fusión. Ambos conceptos se complementan — no se reemplazan.

Quiz: Git Flow

Comprobá que dominás las ramas, los prefijos y el flujo del equipo antes de continuar.