Introducción a la metodología GitFlow

Esta entrada es la última de la serie “Introducción a Git y el control de versiones” escrita para explicar que es Git y como se puede utilizar en equipos de trabajo. Entrada en la que se analizaran la metodología GitFlow.

La serie de publicaciones consta de las siguientes entradas:

1. Introducción a Git y el control de versiones
2. Comandos avanzados de Git y su aplicación
3. Mejores prácticas en Git
4. Introducción a la metodología GitFlow

En esta entrada, se explorarán los conceptos clave de GitFlow, sus principales ramas, explicando cómo utilizar esta metodología en un proyecto real y repasando las mejores prácticas para su adopción por parte de un equipo de trabajo.

¿Qué es GitFlow?

GitFlow es una metodología de control de versiones desarrollada por Vincent Driessen en 2010. Siendo especialmente útil para proyectos que requieren una estrategia robusta para la gestión del ciclo de vida de las versiones, en especial cuando se trabaja en equipo. Para lo que organiza el desarrollo en varias ramas bien definidas. En GitFlow, cada una de las ramas tiene un propósito específico, lo que facilita la gestión de las características, versiones y correcciones.

La principal ventaja de usar GitFlow es que proporciona un flujo de trabajo claro y estructurado para el desarrollo de software. Facilitando que los equipos trabajen de manera organizada, al ofrecer una metodología para asociar las ramas con funcionalidades o etapas del desarrollo perfectamente definidas.

Trending

Comandos avanzados de Git y su aplicación

Las ramas en GitFlow

GitFlow se apoya en la creación de varias ramas con propósitos específicos. Así, al usar estas ramas en el proyecto, se puede gestionar de manera eficiente las diferentes etapas del ciclo de desarrollo. Las principales ramas que se deben crear son:

Rama main

La rama main (o master, dependiendo del proyecto) es la columna vertebral del repositorio y contiene el código de producción. En GitFlow, main siempre debe estar en estado estable. Esto es, cualquier commit en main debe estar listo para ser lanzado a producción. Por lo que, nunca se deben realizar cambios directamente en main, solamente se deben fusionar las ramas que ya han sido previamente probadas y validadas. Es decir, listas para ser liberadas.

Buenas prácticas:

• Los únicos commits en main deberían provenir de fusiones desde ramas de versiones (release branches) o correcciones críticas (hotfix branches).
• Se recomienda etiquetar (tag) los commits en main para marcar versiones importantes (v1.0, v2.0, etc.).

Rama develop

La rama develop es donde tiene lugar el desarrollo del proyecto. Es la rama base desde la cual se crean otras ramas para desarrollar características, y es aquí donde se fusionan esas ramas una vez completadas. develop contiene el código más reciente que aún no ha sido lanzado a producción, pero que ya ha sido validado internamente. Por lo que tampoco se debe trabajar en esta rama, sino que se deben fusionar características ya probadas.

En resumen, develop es la rama que refleja el estado actual del próximo lanzamiento de software.

Buenas prácticas:

• El código en develop debe ser estable y pasar pruebas internas antes de fusionarse.
• Nunca se debe trabajar directamente en develop. Todo el trabajo debe realizarse en ramas de características que luego se fusionen.

Ramas de características (Feature Branches)

Las ramas de características (feature branches) se crean para desarrollar nuevas funcionalidades o realizar tareas específicas. Cada rama de características se deriva de develop y, una vez se ha completado la tarea y esta ha sido validada, se fusiona de nuevo en develop.

¿Cuándo crear una rama de característica?

Cada vez que se empieza a trabajar en una nueva funcionalidad, se debe crear una nueva rama a partir de develop. Para identificarlas fácilmente, el nombre de la rama comienza con feature, seguido de un texto descriptivo que esté relacionado con la tarea a desarrollar. Esto es, se debe iniciar la rama como se indica a continuación:

git checkout develop
git checkout -b feature/nueva-caracteristica

Una vez que la característica está lista, se fusiona de nuevo en develop:

git checkout develop
git merge feature/nueva-caracteristica

Después de la fusión, se puede eliminar la rama de características:

git branch -d feature/nueva-caracteristica

Buenas prácticas:

• Los nombres de las ramas deben ser descriptivos, por ejemplo: feature/autenticacion-usuarios.
• Las ramas de características deben ser de corta duración. Si una característica se está desarrollando durante un largo periodo, es recomendable sincronizar periódicamente con develop para evitar conflictos.

Ramas de versiones (Release Branches)

Las ramas de versiones (release branches) se utilizan cuando se está preparando una nueva versión para producción. Estas ramas se crean a partir de develop cuando el proyecto ha alcanzado un estado en el que está casi listo para ser lanzado, pero aún es necesario realizar pruebas finales, solucionar bugs o ajustar configuraciones.

Una vez que todo está listo, la rama de versión se fusiona en main y también en develop (para garantizar que cualquier corrección realizada durante la preparación de la versión también se transfiera al código de desarrollo).

git checkout develop
git checkout -b release/v1.0

Una vez que la versión está lista:

git checkout main
git merge release/v1.0
git checkout develop
git merge release/v1.0
git tag -a v1.0 -m "Versión 1.0 lista para producción"

Buenas prácticas:

• Usar ramas de versiones para prepararse para lanzamientos garantiza que develop pueda seguir avanzando mientras se realizan los últimos retoques en la versión.
• Etiqueta los commits en main para marcar versiones importantes.

Ramas de correcciones críticas (Hotfix Branches)

Las ramas de correcciones críticas (hotfix branches) se utilizan cuando es necesario corregir un problema en producción de manera urgente. Estas ramas se crean a partir de main y, una vez que la corrección está lista, se fusionan tanto en main como en develop para garantizar que los cambios también están presentes en el código en desarrollo, evitando la posibilidad de futuros errores regresivos.

git checkout main
git checkout -b hotfix/correccion-urgente

Después de implementar la corrección:

git checkout main
git merge hotfix/correccion-urgente
git checkout develop
git merge hotfix/correccion-urgente
git tag -a v1.0.1 -m "Hotfix: Corrección urgente en la versión 1.0.1"

Buenas prácticas:

• Las ramas de correcciones deben ser usadas solo para problemas urgentes y críticos en producción.
• Una vez fusionadas en main, es necesario asegurarse de fusionarlas también con develop para mantener la coherencia del código.

GitFlow en la práctica: Un ciclo completo

La mejor manera de comprender la metodología GitFlow es mediante un ejemplo completo. Para ello, a continuación, se mostrará un ciclo de desarrollo típico. El de un equipo que está desarrollando una nueva versión de software con una nueva funcionalidad.

Paso 1: Crear una nueva característica

El desarrollo de una nueva funcionalidad se inicia en una nueva rama de características:

git checkout develop
git checkout -b feature/nueva-caracteristica

En esta rama, se desarrolla la funcionalidad, se realizan commits de forma regular, y una vez que está lista, se fusiona de nuevo con develop:

git checkout develop
git merge feature/nueva-caracteristica
git branch -d feature/nueva-caracteristica

Paso 2: Preparar el lanzamiento

Cuando el proyecto ha alcanzado un estado estable y está listo para lanzarse, se crea una rama de versión:

git checkout develop
git checkout -b release/v1.0

En esta rama se realizan los últimos ajustes, como la actualización de archivos de configuración o la corrección de bugs menores. Cuando la versión está lista, se debe fusionar tanto con main como develop:

git checkout main
git merge release/v1.0
git checkout develop
git merge release/v1.0
git tag -a v1.0 -m "Lanzamiento de la versión 1.0"
git branch -d release/v1.0

Paso 3: Resolver una emergencia en producción

Después de lanzar la versión 1.0, se detecta un bug crítico en producción. Para solucionarlo, se crea una rama de corrección urgente (hotfix):

git checkout main
git checkout -b hotfix/correccion-urgente

El bug se corrige en esta rama y, al validar la solución, se fusiona tanto con main como develop para mantener el código consistente:

git checkout main
git merge hotfix/correccion-urgente
git checkout develop
git merge hotfix/correccion-urgente
git tag -a v1.0.1 -m "Corrección urgente para la versión 1.0.1"
git branch -d hotfix/correccion-urgente

Ventajas de la metodología GitFlow

La metodología GitFlow aporta numerosas ventajas a los equipos de desarrollo. Ventajas que se pueden apreciar especialmente cuando los equipo son grandes:

• Organización clara: Cada rama tiene un propósito específico, lo que facilita la comprensión del estado actual del proyecto.
• Separación de responsabilidades: Los desarrolladores pueden trabajar en nuevas características sin interferir con el código en producción o las adaptaciones anteriores a un lanzamiento.
• Facilidad para manejar versiones: Con ramas de versiones dedicadas, es fácil preparar un nuevo lanzamiento mientras se continúa con el desarrollo de nuevas funcionalidades.
• Manejo eficiente de correcciones: Las ramas de correcciones urgentes permiten aplicar parches rápidamente sin interrumpir el flujo de trabajo principal.

Herramientas para implementar GitFlow

Dada la popularidad de GitFlow, existen diferentes herramientas que automatizan el proceso de creación y manejo de ramas con esta metodología. Una de las más populares es git-flow, una extensión para Git que simplifica el uso de esta metodología.

En muchas distribuciones de Linux existen paquetes que instalan esta herramienta. Solamente se debe buscar un paquete llamado git-flow en listado de paquetes. Si la distribución con la que se está trabajando no cuenta con este paquete se puede descargar y bajar el siguiente script:

wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash

En el caso de Mac, se puede ejecutar el script o instar la herramienta con brew:

brew install git-flow

En Windows, se puede instalar git a partir del instalador oficial el cual ya contienen git-flow.

Uso básico de git-flow

Una vez instalada, para inicializar iniciarlizar GitFlow en un proyecto se puede escribir:

git flow init

Esto creará las ramas estándar de GitFlow (main y develop). A partir de ahí, se pueden crear y manejar ramas usando los comandos de git-flow:

• Crear una nueva rama de características: git flow feature start nombre-caracteristica
• Terminar una rama de características y fusionarla en develop: git flow feature finish nombre-caracteristica
• Crear una nueva rama de versión: git flow release start v1.0
• Terminar una rama de versión y fusionarla en main y develop: git flow release finish v1.0
• Crear una nueva rama de corrección urgente: git flow hotfix start correccion-urgente

Beneficios de usar git-flow

• Automatización: Facilita la creación, fusión y eliminación de ramas de acuerdo con la metodología GitFlow.
• Estandarización: Todos los miembros del equipo siguen el mismo flujo de trabajo, lo que reduce errores y malentendidos.

Desventajas y limitaciones de GitFlow

Aunque GitFlow es una metodología popular y eficaz, también tiene algunas limitaciones:

• Complejidad: Puede ser excesivo para proyectos pequeños o de corta duración, donde no se necesita un manejo tan estructurado de ramas.
• Desfase con despliegues continuos: En entornos de integración y entrega continua (CI/CD), GitFlow puede no ser el más adecuado, ya que implica un ciclo de desarrollo más largo, con lanzamientos definidos por ramas de versiones.

Conclusiones

GitFlow es una excelente metodología para organizar el desarrollo de software, especialmente en equipos que trabajan en proyectos de mediana o gran escala. Su enfoque en el uso de ramas permite mantener un flujo de trabajo claro y eficiente, lo que facilita el desarrollo de nuevas características, la gestión de versiones y la resolución de problemas críticos.

Adoptar GitFlow puede llevar tiempo, pero una vez dominado, ayuda a mejorar la productividad y la organización del equipo. Al seguir las buenas prácticas mencionadas y utilizando herramientas como git-flow, los equipos pueden beneficiarse de una mayor claridad y control en el desarrollo de software.

Nota: La imagen de este artículo fue generada utilizando un modelo de inteligencia artificial.