GitFlow es modelo de ramificación de Git que usa ramas de características y varias ramas principales lo cual se vuelve indispensable al momento de trabajar con equípos de desarrollo, no solo para mantener todo más organizado si no que facilita la corrección de errores y la implementación de nuevas características al desarrrollar un producto de software.
Este modelo tiene sus ventajas frente al “Trunk-Based Development”, el cual está orientado a ser más ágil y suele acompañarse de un sistema de testeo robusto y un CI/CD integrado. Sin embargo considerando el tamaño y complejidad de ciertos proyectos GitFlow se suele preferir por ser más seguro al tener revisiones (releases) manuales en softwares críticos.
La idea es la siguiente (GitFlow modificado por mi):
🔹 Ramas principales:
| Rama | Descripción |
|---|---|
| stable | Código estable en producción. Solo se actualiza con versiones probadas. |
| canary | Entorno de pruebas. Aquí se integran nuevas funcionalidades antes de ir a stable. |
| hotfix/* | Para corregir errores críticos en producción (stable). |
🔹 Ramas de desarrollo:
| Rama | Descripción |
|---|---|
| feature/* | Cada programador trabaja en su funcionalidad aquí antes de integrarla a canary. |
| release/* | Se crea cuando se agrupan varias features listas para probarse antes de ir a stable. |
🔹 Flujo de Trabajo:
Desarrollo de Nuevas Funcionalidades:
1. Crear una nueva rama a partir de canary:
git checkout canary
git pull origin canary
git checkout -b feature/nueva-funcionalidad2. Hacer cambios, commits y push:
git add .
git commit -m "Agregar nueva funcionalidad"
git push origin feature/nueva-funcionalidad3. Crear un Pull Request (PR) a canary en GitHub.
Preparación para Producción:
1. Cuando canary tenga suficientes cambios estables, se crea una rama release:
git checkout canary
git pull origin canary
git checkout -b release/v1.0.0
git push origin release/v1.0.02. Se hacen pruebas en el entorno de pruebas (canary).
3. Si hay errores menores, se corrigen directamente en release/v1.0.0 y se fusionan de vuelta a canary.
Lanzar a Producción:
1. Una vez probado, fusionamos release/v1.0.0 en stable:
git checkout stable
git merge --no-ff release/v1.0.0
git push origin stable2. Se crea un tag para marcar la versión:
git tag -a v1.0.0 -m "Lanzamiento de la versión 1.0.0"
git push origin v1.0.03. Se elimina la rama release:
git branch -d release/v1.0.0
git push origin --delete release/v1.0.0Corrección de Errores en Producción (Hotfixes):
1. Si hay un bug urgente en stable, se crea una rama hotfix:
git checkout stable
git checkout -b hotfix/error-critico2. Se corrige el error, se hace commit y push.
3. Se fusiona en stable:
git checkout stable
git merge --no-ff hotfix/error-critico
git push origin stable4. También se fusiona en canary para que futuras versiones lo tengan:
git checkout canary
git merge --no-ff hotfix/error-critico
git push origin canary5. Se elimina la rama hotfix:
git branch -d hotfix/error-critico
git push origin --delete hotfix/error-critico🔹 Resumen de la Estrategia:
✔ stable → Código en producción.
✔ canary → Entorno de pruebas.
✔ feature/* → Desarrollo de nuevas funcionalidades.
✔ release/* → Agrupar cambios listos para producción.
✔ hotfix/* → Correcciones urgentes en producción.
Adicionalmente se puede configurar en GitHub para que elimine automáticamente las ramas de feature/* o hotfix/* después de un merge.
