Introducción a los distintos workflows de git: Gitflow, Github flow, Gitlab flow y Trunk Based Development. Particularidades, ventajas e inconvenientes de cada uno para saber cómo elegir el que mejor se adapte a tu equipo.

1. ¿Cómo elegir tu Workflow
de Git?
https://FractionalCTO.es

2. ¿Qué son los
Workflows
de Git?
• Definen flujos de trabajo para colaborar en
un repositorio entre varias personas
• Especifican una política de ramas. Qué
ramas de larga duración existen y cuales de
corta duración se crean
• Definen cómo se integran los cambios
• Cuál elegir depende de: tamaño y seniority
del equipo, software en desarrollo, nivel de
automatización y frecuencia de releases

3. ¿Qué Git
Workflows hay?
• GitFlow
• Feature branch/Github Flow
• GitLab Flow
• Trunk Based Development

4. GitFlow
• Legacy. Creado en 2010.
• Algo complicado, multitud de ramas.
• Ramas de larga duración:
• Main: Guarda el históricos de releases
• Develop: Rama en la que se integran los cambios
de la siguiente release
• Ramas de corta duración:
• feature/bug/…: Se crea una rama por cada
nueva funcionalidad o bug fix
• release/hotfix…: Se crea una rama por cada
release

5. GitFlow (cont.)
• Al haber tantas ramas es posible que se olvide propagar un cambio
• Dificulta la integración continua. Los cambios pueden tardar días e incluso semanas
hasta que se integran y despliegan
• Hay más tiempo (y etapas) para revisar y validar los cambios antes de desplegar en
Producción
• Se emplea más tiempo en la gestión de ramas e integración

6. Feature-
branch/GitHub Flow
• Cortos ciclos de desarrollo y
despliegues más frecuentes
• Ramas de larga duración:
• Main: Rama de integración
• Ramas de corta duración:
• features/… : Una rama por nueva
funcionalidad o bug fix
• 1 – Despliegue + Testing de rama
• 2 – Mergeo a main

7. GitLab Flow
• Parecido a Github Flow pero incluye
ramas para los entornos
• Ramas de larga duración:
• Main: Rama de integración
• Ramas por entorno:
• Staging, Production, etc..
• Ramas de corta duración:
• features/… : Una rama por nueva
funcionalidad o bug fix

8. GitLab Flow (cont.)
• La release se va promocionando entre entornos (y ramas)
• Cada rama de entorno tiene su propio pipeline de CI/CD para
desplegar
• Permite gestionar fácilmente los despliegues a través de Git
• El repositorio almacena qué versión hay en cada entorno

9. Trunk Based
Development (TBD)
• Se trabaja en 1 sola rama Main (o
trunk)
• Commits, Pushes y Pulls frecuentes
para reducir el tiempo de integración
(Varios por día)
• Todos los commits son deployables
• Uso de feature flags para el trabajo no
finalizado
Source: trunkbaseddevelopment.com

10. Trunk Based
Development (cont.)
• Una feature flag es una variable que permite activar/desactivar el código de una
funcionalidad por configuración.
• TBD es la máxima expresión de Continous Integration.
• Los commits pueden desplegarse el mismo día que se hacen.
• Para equipos con un proceso maduro y buena automatización de tests.

11. Qué Workflow elegir?
• Dependerá del tamaño del equipo, seniority, grado de automatización y ciclos
de entrega del producto
• GitFlow ya no está recomendado salvo para proyectos con ciclos largos y
requisitos de calidad muy altos. Ej: aeronáutica
• TBD y GitHub Flow están recomendado para aplicaciones que se desplieguen
muy frecuentemente, y equipos maduros con un grado de automatización alto
• GitLab Flow para productos que tengan una cadencia de despliegues regular.
Ej: 1 release por Sprint

12. Gracias
Si quieres ayuda para revisar tu Workflow de
Git y ver si es el que mejor se adapta a tu
contexto contáctame por DM.
https://FractionalCTO.es