Branching model o flujo de ramas de Git (Gitflow)

Ultima actualización: 1/Abr/2025

Introducción

El branching model o flujo de ramas de Git es un enfoque que define la forma en que se gestionan las ramas en un repositorio de control de versiones. Es importante para la organización del código fuente en repositorios de control de versiones y principalmente para el trabajo en equipo.

Existen varias estrategias de ramificación (branching models) para Git, cada una con sus propias ventajas y desventajas. Para proyectos de ciencia de datos se recomienda usar un gitflow por que 👍

Versionado claro de modelos y experimentos:
- Los proyectos de ciencia de datos suelen implicar muchos experimentos y modelos en evolución.
- Con Gitflow, puedes trabajar en diferentes ramas de características (features) o experimentos sin afectar el código de producción.
Separación entre experimentación y producción:
- El uso de ramas de desarrollo permite experimentar libremente mientras mantienes la rama principal estable.
- Esto es especialmente importante cuando los modelos están en producción y no pueden sufrir interrupciones.
Colaboración y revisión estructurada:
- Facilita la colaboración entre equipos, ya que las ramas de características (features) permiten trabajar de manera aislada y luego integrar los cambios.
- Además, se pueden realizar revisiones de código antes de fusionar a la rama principal.
Gestión de versiones de modelos:
- Permite manejar múltiples versiones de un modelo, lo cual es crucial para reproducibilidad y auditoría.
- Las ramas de release permiten preparar y documentar nuevas versiones de modelos antes de su despliegue.
Control de calidad y pruebas:
- Las ramas de hotfix permiten corregir errores rápidamente sin interrumpir el desarrollo continuo en la rama develop.

¿Qué es Gitflow?

Gitflow es un modelo de ramificación (branching model) para Git, diseñado por Vincent Driessen en 2010, que define una estructura de ramas estricta y roles específicos para diferentes tipos de ramas. Este flujo de trabajo proporciona un marco robusto para gestionar proyectos de software, especialmente aquellos con ciclos de lanzamiento programados y múltiples desarrolladores trabajando simultáneamente.

El modelo Gitflow establece convenciones para nombrar ramas y define el papel específico que diversos tipos de ramas deben tener en el proceso de desarrollo, facilitando el desarrollo paralelo, la colaboración y el control de versiones.

Características principales

Flujo estructurado: Define un proceso claro para el desarrollo, prueba y lanzamiento de software.
Aislamiento de trabajo: Permite a los desarrolladores trabajar en funcionalidades de forma aislada sin afectar al código principal.
Organización de lanzamientos: Proporciona una estructura para preparar y mantener versiones específicas del software.
Gestión de hotfixes: Incluye procesos para gestionar la corrección de errores críticos en producción.
Compatibilidad con desarrollo paralelo: Facilita que múltiples equipos trabajen en diferentes características simultáneamente.
Integración continua: Se integra bien con sistemas de CI/CD para automatizar pruebas y despliegues.

Ramas principales

En el modelo Gitflow existen dos ramas principales que tienen una vida infinita:

Rama `master` (o `main`)

Es la rama que contiene el código que está en producción.
Cada commit en esta rama representa una nueva versión de producción.
No se debe hacer commits directamente sobre esta rama; en su lugar, se integran cambios desde otras ramas específicas.
Todos los commits en esta rama suelen estar etiquetados con números de versión.

Rama `develop`

Es la rama principal de desarrollo, donde se integran todas las funcionalidades completadas.
Sirve como rama de integración para todas las características en desarrollo.
Cuando esta rama alcanza un punto estable y está lista para un lanzamiento, los cambios se fusionan con master a través de una rama de lanzamiento.
Representa el estado más reciente del desarrollo que pasará eventualmente a producción.

Ramas de soporte

Además de las ramas principales, Gitflow define varias ramas de soporte con propósitos específicos y tiempo de vida limitado:

Ramas de funcionalidad (`feature`)

Se crean a partir de la rama develop.
Cuando la funcionalidad está completa, se fusionan de vuelta a develop.
Convención de nomenclatura: feature/nombre-de-la-funcionalidad.
Utilizadas para desarrollar nuevas características o funcionalidades.
Existen mientras la funcionalidad está en desarrollo y se eliminan una vez fusionadas.

Ramas de corrección (`hotfix`)

Se crean a partir de master.
Se utilizan para corregir rápidamente errores críticos en producción.
Una vez completadas, se fusionan tanto en master como en develop (o la rama de lanzamiento actual).
Convención de nomenclatura: hotfix/nombre-del-error o hotfix/versión.
Permiten que el equipo responda a problemas en producción sin interrumpir el flujo de trabajo de desarrollo.

Ramas de lanzamiento (`release`)

Se crean a partir de develop cuando está casi lista para convertirse en un lanzamiento.
Permiten preparaciones de último minuto, correcciones menores y ajustes antes de pasar a producción.
Se fusionan tanto en master (con una etiqueta de versión) como en develop una vez completadas.
Convención de nomenclatura: release/versión.

Proceso de la rama de publicación (Release Branch)

La rama de publicación o release branch juega un papel crucial en el ciclo de lanzamiento de Gitflow:

Creación

Se crea a partir de la rama develop cuando está lista para preparar un lanzamiento.
Se le asigna el número de versión del próximo lanzamiento.
A partir de este punto, no se añaden nuevas funcionalidades a esta rama, solo correcciones de errores y mejoras menores.

Finalización

Cuando la rama de lanzamiento está lista para publicación, se fusiona con master.
El commit en master se etiqueta con el número de versión para fácil referencia futura.
Los cambios realizados en la rama de lanzamiento también se fusionan de vuelta a develop.
Una vez completadas las fusiones, la rama de lanzamiento se elimina.

Propósito

Permite a un equipo preparar el lanzamiento mientras otros desarrolladores continúan trabajando en nuevas funcionalidades para próximos lanzamientos.
Proporciona un período de “congelación de características” (feature freeze) para enfocarse en pulir y estabilizar el código antes de lanzarlo.
Facilita la corrección de errores de último minuto sin interrumpir el desarrollo principal.

Ventajas de utilizar Gitflow

Desarrollo paralelo

Permite que múltiples desarrolladores trabajen simultáneamente en diferentes características sin interferir entre sí.
Separa el trabajo en progreso del código estable, reduciendo conflictos y dependencias.

Colaboración

Proporciona una estructura clara que facilita la colaboración entre equipos.
Define roles específicos para cada rama, lo que reduce la confusión sobre dónde debe ocurrir cada tipo de cambio.

Control de versiones robusto

Mantiene un historial limpio y significativo mediante la separación de funcionalidades, correcciones y lanzamientos.
Facilita la reversión a versiones anteriores si surge algún problema.

Gestión de lanzamientos

Facilita la planificación y ejecución de lanzamientos programados.
Permite ciclos de desarrollo predecibles y controlados.

Respuesta a errores

Proporciona un mecanismo claro para abordar errores urgentes en producción mediante ramas hotfix.
Minimiza el impacto de las correcciones urgentes en el trabajo de desarrollo en curso.

Mantenimiento a largo plazo

Facilita el mantenimiento de múltiples versiones de software en producción.
Permite dar soporte a versiones anteriores mientras se desarrollan nuevas funcionalidades.

Gitflow en ciencia de datos

En proyectos de ciencia de datos, Gitflow puede adaptarse para:

Gestionar versiones de modelos de machine learning.
Separar el trabajo experimental del código de producción.
Coordinar equipos de ingenieros de datos, científicos de datos y desarrolladores.
Implementar procesos de revisión de código antes de integrar cambios.
Mantener versiones estables de pipelines de datos y modelos.

Consideraciones para proyectos pequeños

Aunque Gitflow es muy completo, puede resultar excesivo para proyectos pequeños o equipos reducidos. En estos casos, se pueden considerar alternativas más ligeras como:

GitHub Flow: Más simple, con una rama principal y ramas de características.
Trunk-Based Development: Desarrollo principalmente en la rama principal con ramas de corta duración.

La clave es adaptar el flujo de trabajo al tamaño y complejidad del proyecto, utilizando las partes de Gitflow que agreguen valor sin crear sobrecarga innecesaria.

Referencias

Jose R. Zapata