Merge vs Rebase - Guía de Decisión

Tabla de contenidos

1. El dilema
2. Merge explicado
3. Rebase explicado
4. Tabla comparativa
5. Guía de decisión

1. El dilema

Desarrollas en una rama. Main ha avanzado. ¿Cómo integrar?

    A---B---C main
   /
  D---E feature-branch

2 opciones:

• MERGE: fusionar con un commit de merge
• REBASE: "desplazar" tus commits después de main

¿Cuál elegir? Depende de tu objetivo.

Volver a la tabla de contenidos

2. Merge explicado

Comando:

git checkout main
git merge feature-branch

Resultado visual:

    A---B---C-------M main
   /               /
  D---E-----------/  (M = merge commit)

Qué ocurre:

1. Git crea un commit nuevo (M)
2. Ese commit combina los cambios de las 2 ramas
3. El historial muestra que hubo 2 líneas de desarrollo

Ventajas:

• ✅ Historial veraz: se ve que hubo 2 desarrollos en paralelo
• ✅ Simple: un solo comando, una sola resolución de conflicto
• ✅ Seguro: nunca altera los commits existentes
• ✅ Estándar: enfoque por defecto en la mayoría de los equipos

Inconvenientes:

• ❌ Historial complejo: muchos merge commits
• ❌ Menos legible: cuesta seguir la evolución lineal

Volver a la tabla de contenidos

3. Rebase explicado

Comando:

git checkout feature-branch
git rebase main

Resultado visual:

    A---B---C---D'---E' main

Qué ocurre:

1. Git "despega" tus commits D y E
2. Los "reproduce" después del commit C
3. Crea commits nuevos D' y E' (mismos cambios, hashes nuevos)
4. El historial queda lineal

Ventajas:

• ✅ Historial limpio: línea recta, fácil de leer
• ✅ Fast-forward merge: sin commit de merge
• ✅ Como una historia: como si hubieras desarrollado después de main

Inconvenientes:

• ❌ Reescribe el historial: D y E se convierten en D' y E'
• ❌ Más complejo: varias resoluciones de conflicto posibles
• ❌ Peligroso: ¡nunca hagas rebase de commits compartidos!

Volver a la tabla de contenidos

4. Tabla comparativa

Volver a la tabla de contenidos

5. Guía de decisión

Usa MERGE cuando:

Situaciones:

• Empiezas con Git
• Trabajas en equipo
• Quieres conservar el historial "real"
• Quieres la solución más segura
• Fusionas ramas de larga duración

Comandos:

git checkout main
git pull origin main
git merge feature-branch
git push origin main

Usa REBASE cuando:

Situaciones:

• Quieres un historial limpio y lineal
• Tu rama es corta y personal
• Aún no has compartido tus commits
• Tu equipo prefiere el historial lineal
• Dominas bien Git

Comandos:

git checkout feature-branch
git rebase main               # Resolver conflictos si hace falta
  git checkout main
git merge feature-branch      # Fast-forward merge
  git push origin main
  ```

### **REGLA DE ORO:**

**NEVER REBASE SHARED COMMITS !**

```bash
# PELIGRO - NUNCA hagas esto:
git push origin feature-branch    # Commits compartidos
git rebase main                   # Reescribe commits compartidos = CAOS en el equipo

# OK - rebase solo en local:
git rebase main                   # Commits todavía locales = OK
git push origin feature-branch    # Push después del rebase = OK

Recomendación por nivel:

Estrategias de equipo populares:

1. "Merge only": simple, seguro, historial completo
2. "Rebase then merge": rebase local + merge en main
3. "Squash merge": 1 commit por feature (estilo GitHub)

Lo importante = la coherencia en el equipo, no la perfección técnica.

Volver a la tabla de contenidos