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:
- Introducción a Git y el control de versiones
- Comandos avanzados de Git y su aplicación
- Mejores prácticas en Git
- 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.
Tabla de contenidos
- 1 ¿Qué es GitFlow?
- 2 Las ramas en GitFlow
- 3 GitFlow en la práctica: Un ciclo completo
- 4 Ventajas de la metodología GitFlow
- 5 Herramientas para implementar GitFlow
- 6 Desventajas y limitaciones de GitFlow
- 7 Conclusiones
¿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.
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 enmain
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 condevelop
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
ydevelop
: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.
Deja una respuesta