Git Flow: cómo organizar el trabajo con ramas en Git

¿Qué es Git Flow?

Git Flow es un modelo de trabajo basado en ramas de Git que propone una estructura concreta para organizar el desarrollo de un proyecto.

La idea principal es separar el desarrollo de nuevas funcionalidades, la preparación de versiones y las correcciones de errores mediante ramas con responsabilidades diferentes.

El modelo utiliza principalmente estas ramas:

main
  |
develop
  |
feature/*
release/*
hotfix/*

Cada una cumple una función específica dentro del flujo de trabajo.

1. La rama main

La rama main representa el código que corresponde a las versiones estables del proyecto.

Cuando una versión está preparada para publicarse, los cambios terminan integrándose en esta rama.

La idea general es mantener en main únicamente código que corresponda a versiones listas para ser entregadas.

2. La rama develop

La rama develop concentra el desarrollo que formará parte de la próxima versión.

Las nuevas funcionalidades suelen integrarse primero aquí antes de preparar una versión estable.

Podemos visualizar la relación de esta manera:

main
 |
 v
versiones estables


develop
 |
 v
próxima versión

De esta forma, el trabajo que todavía está en desarrollo permanece separado del código estable.

3. Las ramas feature/*

Las ramas feature/* se utilizan para desarrollar funcionalidades nuevas de manera aislada.

Normalmente parten de develop y, cuando la funcionalidad está terminada, sus cambios se integran nuevamente en develop.

Por ejemplo:

develop
   |
   +---- feature/login
   |
   +---- feature/reportes

Cada funcionalidad puede desarrollarse sin modificar directamente la rama principal de desarrollo.

4. Las ramas release/*

Una rama release/* se utiliza cuando el contenido de develop está suficientemente preparado y se comienza a trabajar en una nueva versión.

Su objetivo es separar la preparación de esa versión del desarrollo de nuevas funcionalidades.

El flujo puede representarse así:

develop
   |
   +---- release/1.0
             |
             v
        preparación
             |
          main

Durante esta etapa pueden realizarse los ajustes necesarios para dejar preparada la versión antes de integrarla en main y continuar el desarrollo correspondiente en develop.

5. Las ramas hotfix/*

Las ramas hotfix/* se utilizan para corregir problemas que afectan a una versión que ya se encuentra en main.

Parten de main y permiten trabajar en una corrección sin depender del estado actual de develop.

El flujo puede verse así:

main
 |
 +---- hotfix/error
          |
          v
       corrección
          |
       versión

Después de completar la corrección, los cambios deben integrarse en las ramas correspondientes para conservar la corrección tanto en la versión estable como en el desarrollo posterior.

6. Flujo completo

Si observamos todas las ramas juntas, el modelo puede resumirse de esta forma:

                feature/*
                    |
                    v
                 develop
                    |
                    v
                release/*
                    |
                    v
                  main
                    ^
                    |
                hotfix/*

El desarrollo de funcionalidades ocurre en ramas feature/*, esas funcionalidades llegan a develop, una versión puede prepararse mediante release/* y posteriormente integrarse en main.

Cuando aparece un problema en una versión estable, se puede utilizar una rama hotfix/* para trabajar en la corrección.

7. ¿Por qué separar las ramas?

La separación permite distinguir claramente tres tipos de trabajo: desarrollo de nuevas funcionalidades, preparación de versiones y correcciones urgentes sobre versiones estables.

Por ejemplo, una nueva funcionalidad puede seguir desarrollándose en develop mientras una versión estable permanece en main.

Esto evita mezclar directamente cambios que todavía están en desarrollo con el código correspondiente a una versión estable.

8. Un ejemplo sencillo

Supongamos que un proyecto tiene una versión estable en main y el equipo comienza a desarrollar un nuevo sistema de autenticación.

Primero se crea una rama de funcionalidad:

develop
   |
   +---- feature/autenticacion

El trabajo se realiza en esa rama y después se integra en develop.

Cuando el conjunto de cambios que formará la siguiente versión está preparado, puede crearse una rama de lanzamiento:

develop
   |
   +---- release/2.0

Una vez terminada la preparación, la versión se integra en main.

Si posteriormente aparece un error crítico en esa versión, se crea una rama hotfix/* a partir de main para trabajar en la corrección.

9. La idea fundamental

Git Flow no cambia la forma en que Git almacena las versiones. Lo que propone es una organización concreta del trabajo mediante ramas.

Cada rama representa una etapa o propósito diferente dentro del desarrollo:

feature/* -> nuevas funcionalidades
develop    -> integración del desarrollo
release/* -> preparación de una versión
main       -> versiones estables
hotfix/*   -> correcciones sobre versiones estables

Consideraciones

Git Flow es un modelo de trabajo que organiza el desarrollo mediante una estructura de ramas con responsabilidades definidas.

La separación entre feature/*, develop, release/*, main y hotfix/* permite distinguir el desarrollo de funcionalidades, la preparación de versiones y las correcciones sobre versiones estables.

La parte importante no es memorizar solamente los nombres de las ramas, sino comprender qué tipo de trabajo corresponde a cada una y cómo los cambios pasan de una etapa a otra.

© Arturo Juárez Monroy