¿Cuál es la diferencia entre merge y rebase, y cuándo usar cada uno?

Merge une dos ramas creando un merge commit; conserva la historia real tal cual pasó, pero deja un historial ramificado. Rebase reescribe la historia reaplicando tus commits sobre una base nueva; deja un historial lineal y limpio, pero cambia los hashes de los commits. La regla de oro: nunca rebasees historia pública; usa merge para integrar lo compartido.

Los dos sirven para lo mismo (integrar cambios), pero el resultado en el historial es distinto:

• Merge

  • Crea un merge commit con dos padres.
  • Preserva la historia exacta: se ve cuándo y desde dónde se ramificó.
  • Historial más "enredado" pero fiel a la realidad.
  • Seguro en ramas compartidas.

• Rebase

  • Reaplica tus commits encima de otra rama, creando commits nuevos.
  • Historial lineal, fácil de leer.
  • Reescribe la historia (hashes nuevos).
  • Peligroso si la rama ya está publicada.

Cuándo usar cada uno:

• Usa rebase para limpiar tu propia rama local antes de compartirla (ponerla al día con main, ordenar commits).
• Usa merge para integrar ramas ya compartidas, especialmente al llevar una feature a main.

La regla de oro: no rebasees commits que ya subiste y que otros podrían tener. Si ya es público, se integra con merge.

# --- MERGE: integrar feature en main conservando la historia ---
git switch main
git merge feature
# Crea un merge commit (si ambas ramas avanzaron)
# Historial: queda ramificado, con el punto de unión visible

# --- REBASE: poner feature al día con main, historial lineal ---
git switch feature
git rebase main
# Reaplica los commits de feature encima de main
# Historial: queda en línea recta, sin merge commit

# Flujo común y seguro:
# 1. rebase local para limpiar/actualizar tu rama
git switch feature
git rebase main
# 2. merge para integrar a la rama compartida
git switch main
git merge feature

Rebasear una rama compartida y provocarles conflictos y confusión a los compañeros, porque los commits que ellos tenían ahora tienen hashes distintos. El otro extremo también existe: llenar el historial de merge commits innecesarios cuando un rebase local habría dejado todo más limpio. La clave es público = merge, local = rebase si quieres limpiar.

"Los dos integran cambios, pero el merge crea un merge commit y conserva la historia tal como pasó, dejando un historial ramificado y seguro para ramas compartidas. El rebase reescribe la historia reaplicando mis commits sobre otra base, dejando un historial lineal y limpio, pero con hashes nuevos. Uso rebase para limpiar o actualizar mi rama local antes de compartirla, y merge para integrar lo que ya es público. La regla de oro es no rebasear nunca historia que otros ya tienen."