Los flujos de trabajo (workflows) en Git definen cómo un equipo utiliza Git para colaborar en el desarrollo de software. Estos flujos permiten gestionar el ciclo de vida de un proyecto de manera organizada y eficiente, asegurando que las ramas se manejen correctamente, las características se integren de forma controlada, y los errores se resuelvan rápidamente. A continuación, se detallan tres de los flujos de trabajo más populares: GitFlow, GitHub Flow y GitLab Flow.

GitFlow: Flujos de trabajo en equipos

GitFlow es una estrategia popular y estructurada para gestionar ramas y versiones en proyectos de desarrollo. Fue diseñado para equipos que siguen ciclos de desarrollo tradicionales con lanzamientos planificados. GitFlow introduce un conjunto de ramas especializadas y define cómo deben interactuar durante el desarrollo.

Ramas principales en GitFlow

main: Esta es la rama principal de producción. Contiene el código que siempre debe estar estable y listo para ser lanzado. Solo se fusionan en main ramas que representan versiones completamente testeadas y listas para producción.
develop: Es la rama de desarrollo. Aquí se integran todas las nuevas funcionalidades y cambios antes de que sean liberados. El código en develop puede no estar siempre estable, pero representa el progreso continuo del proyecto.

Ramas de soporte

Además de las ramas principales, GitFlow utiliza otras ramas de soporte para organizar el ciclo de desarrollo y el lanzamiento:

Feature branches (ramas de características):
- Se crean a partir de develop para desarrollar nuevas funcionalidades.
- Se nombran como feature/nombre-característica.
- Una vez completadas, se fusionan de nuevo en develop.
- Crear una nueva feature branch:
```
1git checkout -b feature/agregar-autenticación develop
```
Release branches (ramas de lanzamiento):
- Se crean a partir de develop cuando se está listo para preparar una nueva versión para su lanzamiento.
- Permiten realizar los últimos ajustes y pruebas antes de liberar el código.
- Una vez finalizada, se fusiona en main y en develop.
- Crear una release branch:
```
1git checkout -b release/1.0 develop
```
Hotfix branches (ramas de corrección urgente):
- Se crean a partir de main cuando hay errores críticos en producción que necesitan ser corregidos inmediatamente.
- Una vez corregidos, se fusionan tanto en main como en develop para asegurarse de que las correcciones también estén en la rama de desarrollo.
- Crear una hotfix branch:
```
1git checkout -b hotfix/corregir-bug main
```

Flujo de trabajo típico en GitFlow

Crear una rama feature/ para desarrollar una nueva funcionalidad.
Fusionar la rama de características en develop una vez que esté completa.
Cuando el desarrollo esté listo para un lanzamiento, crear una rama release/ desde develop para los últimos ajustes.
Fusionar la rama release/ en main y marcar la versión con una etiqueta (tag).
Si es necesario, crear una rama hotfix/ para corregir errores críticos.

GitHub Flow: Uso de ramas para integración continua

GitHub Flow es un flujo de trabajo más simple y ágil que GitFlow. Se basa en la integración continua y es ideal para proyectos que requieren despliegues frecuentes y rápidos. GitHub Flow es popular en proyectos donde los desarrolladores despliegan cambios a producción regularmente, sin depender de ciclos de desarrollo largos.

Principios básicos de GitHub Flow

Una rama principal (main): El código en la rama main siempre debe estar en un estado que pueda desplegarse en producción. Cada commit a main representa un paso hacia la producción.
Ramas cortas de características: Cada nueva funcionalidad o corrección de errores se desarrolla en una rama separada creada desde main. Estas ramas se crean con un propósito específico y se eliminan después de fusionarlas.
Pull requests para integración: Cuando una rama de características está lista, se abre un pull request para revisión y discusión. Una vez aprobado, se fusiona en main y el código está listo para ser desplegado.

Flujo de trabajo típico en GitHub Flow

Crear una nueva rama de características desde main:

1git checkout -b feature/agregar-pago main

Desarrollar y hacer commits en la nueva rama.
Abrir un pull request para revisión y fusión en main.
Revisión y aprobación: Otros desarrolladores revisan el pull request y hacen sugerencias.

Fusión en main una vez que el pull request es aprobado:

1git checkout main
2git merge feature/agregar-pago

Desplegar a producción directamente desde la rama main.

Ventajas de GitHub Flow

Simplicidad: Solo necesitas trabajar con una rama principal (main) y ramas temporales para funcionalidades o correcciones.
Integración continua: Permite a los equipos integrar y desplegar cambios de manera rápida y frecuente, favoreciendo ciclos cortos de desarrollo.
Ideal para desarrollo ágil: GitHub Flow se adapta bien a proyectos donde los despliegues son frecuentes y no hay grandes ciclos de desarrollo o lanzamientos.

GitLab Flow: Proyectos de entrega continua

GitLab Flow es una variante que mezcla conceptos de GitFlow y GitHub Flow, pero introduce una capa adicional para la entrega continua (continuous delivery). Está diseñado para proyectos donde se gestiona tanto el código como el despliegue a diferentes entornos (como desarrollo, preproducción y producción).

Principios básicos de GitLab Flow

Ramas principales (main y otras según los entornos): A diferencia de GitHub Flow, GitLab Flow sugiere tener ramas que correspondan a los diferentes entornos en los que se despliega el código, como main (producción), staging (preproducción) y develop (desarrollo).
Fusión basada en entornos: Los cambios se fusionan en ramas específicas según el entorno al que estén destinados. Por ejemplo, los cambios listos para producción se fusionan en main, mientras que los cambios en desarrollo se fusionan en develop.
Control de versiones con etiquetas: Los lanzamientos se marcan con etiquetas (tags) que indican la versión liberada.

Flujo de trabajo típico en GitLab Flow

Crear una rama de características desde develop para trabajar en una nueva funcionalidad:

1git checkout -b feature/integrar-API develop

Desarrollar la funcionalidad y hacer commits en la nueva rama.

Fusión en la rama develop una vez que el trabajo esté completo:

1git checkout develop
2git merge feature/integrar-API

Pasar los cambios a staging para pruebas:

1git checkout staging
2git merge develop

Desplegar a producción fusionando en main:

1git checkout main
2git merge staging

Ventajas de GitLab Flow

Control sobre los entornos de despliegue: GitLab Flow permite gestionar el despliegue a diferentes entornos de manera clara, lo que es útil en proyectos con múltiples entornos (desarrollo, pruebas, producción).
Integración con CI/CD: GitLab Flow se integra fácilmente con GitLab CI/CD, lo que permite automatizar el proceso de despliegue en cada entorno.

Uso de etiquetas en GitLab Flow

Una vez que los cambios se han fusionado en main, puedes crear una etiqueta para marcar la versión:

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

Resumen

Cada uno de estos flujos de trabajo con Git está diseñado para satisfacer diferentes necesidades de desarrollo:

GitFlow: Ideal para proyectos con ciclos de desarrollo más tradicionales y planificación de versiones, donde se requiere una estructura rígida para manejar ramas y lanzamientos.
GitHub Flow: Simplicidad y agilidad, perfecto para equipos que practican integración y despliegue continuo, con ramas pequeñas y rápidas.
GitLab Flow: Enfocado en la entrega continua, útil para proyectos que necesitan gestionar múltiples entornos de despliegue.

Cada equipo puede elegir el flujo de trabajo que mejor se adapte a sus necesidades, y estos flujos pueden incluso combinarse o ajustarse a las particularidades del proyecto. Si necesitas más ejemplos o una implementación más detallada de cualquiera de estos flujos, ¡solo avísame!

Curso git nivel medio