Tabla de contenido

Cuando trabajas solo en un proyecto pequeño, hacer commits directamente a main funciona. Pero cuando hay más de una persona en el equipo, o cuando necesitas gestionar versiones y despliegues, necesitas una estrategia de ramas clara. Git Flow es una de las más adoptadas.

¿Qué es Git Flow?

Git Flow es una estrategia de ramificación para Git propuesta por Vincent Driessen en 2010. Define un conjunto de reglas sobre cómo crear ramas, cuándo mergearlas y cómo gestionar versiones y hotfixes.

No es una herramienta en sí (aunque existe una extensión llamada git-flow), sino una convención que tu equipo adopta. El objetivo es mantener el código organizado y garantizar que main siempre tenga código listo para producción.

Las ramas principales

Git Flow define dos ramas que existen de forma permanente:

main (o master): Contiene el código que está en producción. Solo recibe merges desde release y hotfix. Cada merge a main es una nueva versión en producción y se etiqueta con un tag de versión (v1.0.0, v1.1.0, etc.).

develop: Es la rama de integración. Aquí es donde se juntan todas las nuevas funcionalidades antes de ir a producción. Es la rama “más adelantada” del código.

main ─────────────────●──────────────●──── (producción)
                      ↑              ↑
develop ─────●────●───●────●─────●───● ─── (integración)
             ↑    ↑         ↑    ↑
           feat  feat      feat  feat

Ramas de soporte

Git Flow define tres tipos de ramas de soporte que se crean y eliminan según se necesiten:

Feature branches (feature/nombre): Para desarrollar nuevas funcionalidades. Se crean desde develop y se mergean de vuelta a develop.

# Crear desde develop
git checkout develop
git checkout -b feature/login-con-google

# ... trabajas en la funcionalidad ...

# Mergear a develop cuando está lista
git checkout develop
git merge --no-ff feature/login-con-google
git branch -d feature/login-con-google

Release branches (release/version): Cuando develop está lista para una nueva versión, se crea una rama release para preparar el lanzamiento. Solo se hacen correcciones menores (no nuevas funcionalidades). Al terminar se mergea tanto a main (con tag) como a develop.

git checkout develop
git checkout -b release/1.2.0

# Solo bug fixes y ajustes finales...

# Al terminar:
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0

git checkout develop
git merge --no-ff release/1.2.0

git branch -d release/1.2.0

Hotfix branches (hotfix/descripcion): Para corregir bugs críticos en producción. Se crean desde main y al terminar se mergean tanto a main como a develop.

git checkout main
git checkout -b hotfix/corregir-pago-fallido

# Corriges el bug urgente...

git checkout main
git merge --no-ff hotfix/corregir-pago-fallido
git tag -a v1.1.1

git checkout develop
git merge --no-ff hotfix/corregir-pago-fallido

git branch -d hotfix/corregir-pago-fallido

Flujo de trabajo completo

Este es el flujo típico en un equipo con Git Flow:

  1. Nuevo sprint/funcionalidad: Developer crea feature/mi-funcionalidad desde develop
  2. Desarrollo: Trabaja en la feature, hace commits regulares
  3. Code Review: Abre un Pull Request de feature/... hacia develop
  4. Merge: Después de aprobación, se mergea a develop
  5. Preparar release: Cuando hay suficientes features, se crea release/X.Y.0
  6. Testing final: QA prueba en la branch release, se corrigen bugs menores
  7. Deploy: Se mergea a main, se tagea como vX.Y.0, se despliega
  8. Bug crítico en producción: Se crea hotfix/..., se corrige y se mergea a main y develop

Comandos de Git Flow

Puedes instalar la extensión git-flow para simplificar los comandos:

Mac:

brew install git-flow-avh

Linux:

sudo apt-get install git-flow

Inicializar Git Flow en tu repositorio:

git flow init
# Acepta los nombres por defecto (main, develop, feature/, release/, hotfix/)

Trabajar con features:

git flow feature start login-google    # crea feature/login-google desde develop
git flow feature finish login-google   # mergea a develop y elimina la rama
git flow feature publish login-google  # sube la feature a GitHub para PR

Trabajar con releases:

git flow release start 1.2.0           # crea release/1.2.0 desde develop
git flow release finish 1.2.0          # mergea a main y develop, crea tag v1.2.0

Trabajar con hotfixes:

git flow hotfix start corregir-pagos   # crea hotfix/corregir-pagos desde main
git flow hotfix finish corregir-pagos  # mergea a main y develop, actualiza versión

¿Git Flow o Trunk Based Development?

Git Flow tiene críticos que argumentan que es demasiado complejo para muchos equipos modernos. La alternativa más popular hoy en día es Trunk Based Development (TBD): todos trabajan en main (o cerca de ella) con ramas de vida muy corta (horas, no días).

TBD funciona bien cuando:

  • El equipo tiene buena cobertura de tests
  • Se usa CI/CD con deploys continuos
  • Las funcionalidades se protegen con feature flags

Git Flow funciona bien cuando:

  • El equipo gestiona múltiples versiones en producción
  • Los ciclos de release son más largos (semanas, no horas)
  • No hay CI/CD maduro implementado

La mayoría de equipos medianos en México y Latinoamérica usan alguna variante de Git Flow. Entenderlo te dará una ventaja clara en entrevistas y al incorporarte a equipos nuevos.