GitFlow Light

Fuente: diagrama flujo-gmg-gitflow_light_release.drawio del equipo GMG, redibujado aquí con Mermaid para que quede como texto versionado (editable en este mismo repo) en vez de una imagen suelta.

Documentado originalmente para controlgmg-v2. controlgmg-mix lo hereda con una sola diferencia confirmada: su rama principal se llama main, no master — todo lo demás (de dónde nace feature/bugfix, la regla de no arrastrar ambientes, hotfix directo) se asume igual hasta que el equipo confirme un flujo propio para Mix.

El flujo

%%{init: { 'gitGraph': { 'mainBranchName': 'master' } } }%%
gitGraph
    commit id: "master"
    branch develop
    branch staging
    branch release
    checkout master
    branch "feature/JIRA-XXX"
    commit id: "trabajo"
    checkout develop
    merge "feature/JIRA-XXX" id: "PR → dev (testeo)"
    checkout staging
    merge "feature/JIRA-XXX" id: "PR → staging"
    checkout release
    merge "feature/JIRA-XXX" id: "PR → release"
    checkout master
    merge release id: "PR → master" tag: "versionado"
    branch "hotfix/JIRA-YYY"
    commit id: "parche urgente"
    checkout master
    merge "hotfix/JIRA-YYY" id: "PR directo"

Lee el diagrama así: la misma rama (feature/JIRA-XXX) se abre PR hacia develop, staging y release por separado — nunca se encadena develop → staging → release fusionando ambientes entre sí. Es la regla más importante de este flujo (ver #4 más abajo) y la razón de que se llame “light”: los ambientes no acumulan merges de otros ambientes, solo reciben la rama de origen cada vez.

Ambientes y ramas

Ambiente	Rama	URL
—	bugfix/* · feature/*	(no se despliega sola)
DEV	develop	dev.controlgmg.com
QA	staging	qa.controlgmg.com
—	release	(zona de amortiguamiento antes de producción)
PRD	master	controlgmg.com
—	hotfix/*	(parche directo a master)

De dónde nace cada rama

• feature/ y bugfix/ nacen siempre de master, y se mantienen activas durante todo el flujo — no se borran (ni en ambientes locales) hasta que llegan a staging (ver regla de oro #3).
  • feature/ = nueva funcionalidad o característica (ej. un botón nuevo).
  • bugfix/ = corrige un error o problema ya existente (ej. un error en el login).
  • Prefijo obligatorio con el código del issue del tablero — JIRA-123-mi-commit — tanto en el nombre de la rama como en cada commit.
  • Sourcetree, GitKraken y clientes similares no soportan crear bugfix desde su panel de GitFlow — se crea manualmente.
• hotfix/ nace también de master, para parches urgentes de producción. Se mezcla directo a master, sin pasar por develop/staging/release.

Inconsistencia detectada en el diagrama original — pendiente de aclarar

Un recuadro de texto del .drawio original dice “feature nace de staging”, pero el rótulo del propio swimlane (más autoritativo) dice “Nace de master, se queda siempre activa” — y coincide con la regla confirmada por el equipo. Esta página documenta la regla de master. Vale la pena confirmar con quien mantiene el diagrama original y corregir ese recuadro si fue un error de redacción.

Reglas de oro

#	Regla
1	Antes de cualquier merge, hacer pull de la rama destino.
2	El prefijo del issue (JIRA-123-slug) va en el nombre de la rama y en cada commit.
3	Una rama feature/bugfix no se borra (ni en ambientes locales) hasta que llega a staging.
4	Lo que se promueve de un ambiente al siguiente es la rama origen, nunca la rama del ambiente — develop/staging no se mezclan hacia adelante.
5	hotfix/ es la única rama que se salta develop/staging/release e impacta master directo.

Por qué importa la regla #4

Si una rama de trabajo nace de develop (o cualquier ambiente intermedio) en vez de master, al promoverla terminas arrastrando todo lo que ese ambiente tenga de más sobre master — incluyendo trabajo de otros que todavía no debía publicarse. Esto pasó en la práctica el 2026-10-30 con la rama de instalación de este mismo Docu (GMG-3169): se creó por error desde develop (208 commits de diferencia con master) y hubo que rehacerla desde cero.