GitLab Flow

GitHub Flow más ramas de ambiente (staging, production) o de release, con regla de "upstream first".

Contexto

Equipos que quieren la simplicidad de GitHub Flow, pero necesitan promover cambios por ambientes (staging, pre-producción, producción) o mantener versiones estables de un producto.

Solución

Parte de main y agrega ramas según la necesidad. Hay dos variantes:

1. Ramas de ambiente (entrega continua con aprobaciones):

feature ──▶ main ──▶ staging ──▶ production

El código solo se promueve hacia la derecha (merge de main a staging, y de staging a production).

2. Ramas de release (software versionado):

main ──●──●──●──●──▶
          \     \
           2-3-stable   2-4-stable   ← fixes entran a main y se cherry-pickean

Regla clave: upstream first. Un fix se hace siempre en main primero y recién después se lleva a las ramas de ambiente o de release. Así ningún bug queda corregido solo en una rama.

#Cuándo encaja

  • Hay un entorno de staging con validación manual o aprobación obligatoria (compliance).
  • No podés desplegar a producción cada vez que se mergea a main.
  • Soportás algunas versiones paralelas, pero no tantas como para necesitar GitFlow completo.
Cuándo NO aplicarlo
  • Si desplegás directo desde main a producción: GitHub Flow alcanza.
  • Las ramas de ambiente se vuelven un "pipeline manual": si cada promoción es un merge a mano, automatizalo.
Tradeoffs
Pro Contra
Soporta ambientes y aprobaciones explícitas Más ramas que GitHub Flow
Más simple que GitFlow La promoción manual entre ambientes frena el flujo
"Upstream first" evita regresiones Requiere disciplina con cherry-picks

#git #branching #gitlab #environments