¿Cuál es la diferencia entre rebase y merge?

Question

Accepted Answer

Tanto **merge** como **rebase** integran cambios de una rama a otra, pero lo hacen de manera diferente: merge **preserva el historial** con un commit de merge, mientras que rebase **reescribe el historial** para crear una secuencia lineal. Comprender la diferencia y cuándo usar cada uno es importante.

## Por qué es importante

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — reescribe para un historial lineal (reproduce)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **mueve** los commits de tu rama para que comiencen desde la punta de otra rama, creando nuevos commits — produciendo un historial limpio y lineal.

## La regla de oro del rebase

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## Cuándo usar cada uno

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## Por qué es importante

Comprender la diferencia entre rebase y merge es importante porque ambos integran cambios pero con efectos fundamentalmente diferentes en el historial, y elegir correctamente (y de manera segura) importa, por lo que es conocimiento de Git valioso que también se discute comúnmente.

La distinción central — **merge preserva el historial** (creando un commit de merge que registra las ramas combinadas, manteniendo el historial de desarrollo verdadero) mientras que **rebase reescribe el historial** (reproduciendo commits en la punta de otra rama para crear una secuencia limpia y lineal como si el trabajo se hubiera realizado en el código más reciente) — afecta cómo se ve y se lee el historial del proyecto.

Comprender los trade-offs (merge: preciso pero potencialmente desordenado con commits de merge; rebase: limpio y lineal pero reescribiendo commits) ayuda a elegir según si valoras el historial verdadero o la limpieza lineal.

Más críticamente, comprender la **regla de oro del rebase** — **nunca hagas rebase en commits que han sido enviados/compartidos** — es esencial porque rebase reescribe commits (dándoles nuevos hashes), por lo que hacer rebase en historial compartido diverge de lo que tus colaboradores tienen, causando confusión grave y conflictos; rebase es seguro solo para commits locales no enviados.

Esta regla de seguridad es vital y una fuente común de problemas cuando se viola.

Comprender **cuándo usar cada uno** (merge para integrar ramas compartidas y preservar el historial, a menudo el default del equipo para fusionar características vía pull requests; rebase para limpiar commits locales antes de compartir o mantener una rama de características lineal — solo en commits locales) refleja una práctica sólida de Git.

Ya que integrar cambios es fundamental y la elección merge-vs-rebase (con sus implicaciones de historial y seguridad) es una decisión frecuente y tema de entrevista, comprender la diferencia — sus efectos en el historial, la regla de oro crítica, y cuándo usar cada uno — es conocimiento de Git valioso y prácticamente importante que es central para mantener un historial limpio de manera segura y una distinción comúnmente discutida que todo desarrollador debe comprender.