GitFlow

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:

Bash

git checkout canary
git pull origin canary
git checkout -b feature/nueva-funcionalidad

2. Hacer cambios, commits y push:

Bash

git add .
git commit -m "Agregar nueva funcionalidad"
git push origin feature/nueva-funcionalidad

3. 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:

Bash

git checkout canary
git pull origin canary
git checkout -b release/v1.0.0
git push origin release/v1.0.0

2. 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:

Bash

git checkout stable
git merge --no-ff release/v1.0.0
git push origin stable

2. Se crea un tag para marcar la versión:

Bash

git tag -a v1.0.0 -m "Lanzamiento de la versión 1.0.0"
git push origin v1.0.0

3. Se elimina la rama release:

Bash

git branch -d release/v1.0.0
git push origin --delete release/v1.0.0

Corrección de Errores en Producción (Hotfixes):

1. Si hay un bug urgente en stable, se crea una rama hotfix:

Bash

git checkout stable
git checkout -b hotfix/error-critico

2. Se corrige el error, se hace commit y push.

3. Se fusiona en stable:

Bash

git checkout stable
git merge --no-ff hotfix/error-critico
git push origin stable

4. También se fusiona en canary para que futuras versiones lo tengan:

Bash

git checkout canary
git merge --no-ff hotfix/error-critico
git push origin canary

5. Se elimina la rama hotfix:

Bash

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.