Git — Merge Strategy

Merge Strategy — Squash en main, Merge en el resto

El equipo aplica el Squash única y exclusivamente al integrar cambios a la rama main. Para el resto de las integraciones se utiliza merge directo para preservar el historial detallado.

Tu rama (múltiples commits)

feat: agrega formulario

fix: corrige validación

refactor: limpia código

feat: completa el flujo

→

En main (un commit limpio)

Agrega login con Google, rel #456

Estrategia por destino

Destino del merge	Estrategia	Justificación
`testing`	Merge directo (sin MR, sin squash)	Preserva historial completo para troubleshooting de QA.
`next / stage`	Merge directo (sin MR, sin squash, solo TL/PM)	Historial detallado, requiere aprobación de Maintainer.
`main`	Squash & Merge vía MR	Un commit limpio por feature, facilita rollback y changelog.

Beneficios del squash solo en `main`

📖El historial de main queda limpio y semántico: cada commit representa una feature o fix completo.

🔙Facilita hacer revert de una feature completa con un solo comando si algo falla en producción.

📋Permite generar changelogs automáticos.

🔍testing y next conservan el historial detallado que QA y maintainers necesitan para depuración.

Cómo configurarlo en GitLab

Settings → General → Merge requests:

Squash commits when mergingEncourage / Require

Pipelines must succeedActivado

All discussions must be resolvedActivado

Delete source branch after mergeActivado

Crítico: El título del squash commit en GitLab se toma del título del MR. Por eso es esencial que el título del MR sea claro y siga el formato establecido.

Merge Strategy — Squash en main, Merge en el resto

Estrategia por destino

Beneficios del squash solo en main

Cómo configurarlo en GitLab

Anexo: Diagrama de Estrategia de Merge

Beneficios del squash solo en `main`