Merge vs Rebase - Estudio de Caso — Git avanzado y GitHub

Tabla de contenidos

El problema
Solución 1: merge
Solución 2: rebase
Comparación práctica
¿Qué enfoque elegir?

1. El problema

Situación típica:

Desarrollas en feature-branch
Mientras tanto, main avanza (los compañeros hacen push)
Quieres integrar tu trabajo en main

2 estrategias posibles:

MERGE: fusionar las ramas
REBASE: reescribir el historial

Volver a la tabla de contenidos

2. Solución 1: merge

Preparación del escenario:

bash

mkdir demo-merge && cd demo-merge && git init

# Base común
echo "print('app v1')" > app.py
git add . && git commit -m "Versión inicial"

# Rama feature
git checkout -b feature-login  
echo "print('login system')" > login.py
git add . && git commit -m "Add login"
echo "print('login v2')" > login.py  
git add . && git commit -m "Improve login"

# Main avanza mientras tanto
git checkout main
echo "print('app v1.1')" > app.py
git add . && git commit -m "Update main app"

Merge:

bash

git merge feature-login

Resultado del merge:

*   Merge branch 'feature-login'
|\  
| * Improve login
| * Add login  
* | Update main app
|/  
* Versión inicial

Historial: muestra con claridad que hubo 2 líneas de desarrollo en paralelo.

Volver a la tabla de contenidos

3. Solución 2: rebase

Misma preparación, otra estrategia:

bash

mkdir demo-rebase && cd demo-rebase && git init

# La misma preparación que antes...
echo "print('app v1')" > app.py
git add . && git commit -m "Versión inicial"

git checkout -b feature-login  
echo "print('login system')" > login.py
git add . && git commit -m "Add login"
echo "print('login v2')" > login.py  
git add . && git commit -m "Improve login"

git checkout main
echo "print('app v1.1')" > app.py
git add . && git commit -m "Update main app"

Rebase:

bash

git checkout feature-login
git rebase main              # "Desplaza" tus commits después de main
git checkout main  
git merge feature-login      # Fast-forward merge

Resultado del rebase:

* Improve login
* Add login  
* Update main app
* Versión inicial

Historial: lineal, como si hubieras desarrollado después de las actualizaciones de main.

Volver a la tabla de contenidos

4. Comparación práctica

Aspecto	MERGE	REBASE
Historial	Muestra ramas en paralelo	Lineal, limpio
Commit de merge	Sí, se crea automáticamente	No, fast-forward
Complejidad	Simple	Más compleja
Conflictos	Resolverlos 1 vez	Puede que varias veces
Trazabilidad	Se ve cuándo se creó/fusionó la feature	Como si se hubiera desarrollado en secuencia

Visualización lado a lado:

MERGE:

    A---B---C main
   /         \
  D---E---F---G feature (merge commit G)

REBASE:

A---B---C---D'---E'---F' main (commits D,E,F "desplazados")

Volver a la tabla de contenidos

5. ¿Qué enfoque elegir?

Usa MERGE cuando:

Empiezas con Git
Quieres conservar el historial "real"
El equipo trabaja en ramas de larga duración
La seguridad ante todo

Comando:

bash

git checkout main
git merge feature-branch

Usa REBASE cuando:

Quieres un historial limpio y lineal
La feature branch es corta y personal
El equipo prefiere un historial "como una historia"
Dominas bien Git

Comando:

bash

git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch    # Fast-forward

REGLA DE ORO:

¡NUNCA hagas rebase de commits ya compartidos o enviados con push!

Recomendación simple:

Principiante → siempre MERGE
Con experiencia → REBASE en ramas personales, MERGE para compartir

Las dos funcionan. Lo importante = la coherencia en el equipo.