Flujo de trabajo Gitflow

Gitflow es una estrategia de ramificación que organiza el trabajo en diferentes ramas para facilitar el desarrollo colaborativo, la publicación y la corrección de errores.

Ramas principales - Generalmente protegidas y cada solucitud de cambio (PR) requiere aprobación -

• main: Historial de producción y versiones estables.
• develop: Integración de nuevas características y próximas releases.

Ramas secundarias

• feature/*: Nuevas funcionalidades (enhancement/* : mejora a una funcionalidad existente, bugfix/* : Corrección de un error no grave para producción).
• release/*: Preparación para despliegue.
• hotfix/*: Correcciones urgentes en producción.

Pasos para trabajar con Gitflow

1. Crear rama de desarrollo:

   git checkout -b develop main
   git push origin develop

2. Crear una nueva funcionalidad:

   git pull origin develop
   git checkout -b feature/nueva-funcionalidad develop
   ### desarrollar el feature ###
   # durante el desarrollo se pueden hacer commits y push necesarios sobre la rama de desarrollo del feature
   # algunas empresas tiene políticas sobre el volumen de código modificado por PR en cada feature

3. Finalizar la feature y fusionar a develop:

   git pull origin develop
   git add .
   git commit -m “descripción del feaure desarrollado”
   git push origin feature/nueva-funcionalidad
   # Ahora crea un Pull Request (PR) desde la rama feature/nueva-funcionalidad hacia develop en la plataforma de Git (GitHub, GitLab, Azure DevOps, etc.)
   
   # Opcional después de que el PR sea aprobado y mergeado:
   git checkout develop
   git pull origin develop
   git branch -d feature/nueva-funcionalidad

4. Preparar una release:

   git checkout -b release/1.0.0 develop
   git push origin release/1.0.0
   ### Momento de pruebas en el ambiente beta antes de mandar el desarrollo a producción ###
   # Para subir release a producción se hace un PR del release hacia main
   # Existen reglas internas sobre la eliminación de ramas de releases pasados

5. Corrección urgente:

   git checkout -b hotfix/1.0.1 main
   ### Hacer las correcciones urgentes ###
   git add .
   git commit -m "descripcion de la corrección realizada"
   git push origin hotfix/1.0.1
   ### Crear un PR de la rama del hotfix hacia main
   ### Crear el PR de la rama del hotfix hacia develop
   # dependiendo del flujo de trabajo que se tenga, puede ser necesario bajar el cambio de la rama main a la rama release
   
   # Una vez mergeadas las ramas eliminamos la rama del hotfix
   git branch -d hotfix/1.0.1
   git pull origin develop

Buenas prácticas

• Las funcionalidades deben ir en ramas feature/* y siempre fusionarse a develop.
• Las versiones estables solo viven en main.
• Los hotfixes se fusionan tanto en main como en develop.

---