Los dos resuelven lo mismo, de forma distinta

Imagina que tú y un compañero sacaron cada quien su propia rama de main hace unos días, y ahora main tiene commits nuevos que tú no tienes. Antes de subir tu trabajo, necesitas traer esos commits a tu rama. Ahí es donde entran merge y rebase — dos formas de resolver exactamente esa situación, con resultados muy distintos en el historial.

git merge

  • Crea un commit nuevo que une ambas historias
  • No reescribe ningún commit existente
  • El historial muestra ramas y uniones reales
  • Seguro incluso en ramas compartidas

git rebase

  • Mueve tus commits para que parezcan hechos después
  • Reescribe el historial de tu rama por completo
  • El resultado es una línea recta, sin bifurcaciones
  • Peligroso si alguien más ya tiene esos commits

git merge: combina sin tocar el pasado

Parado en tu rama, traer los cambios de main con merge es un solo comando:

git merge main

Esto crea un "commit de merge" — uno nuevo, con dos padres, que marca el punto exacto donde ambas historias se juntaron. Nada de lo que ya existía cambia de lugar ni de identificador. Es la opción más segura porque no le hace nada a commits que otras personas ya podrían tener descargados.

El costo es estético: si tu equipo hace esto seguido, el historial de git log --graph se llena de líneas que se cruzan una y otra vez. Funcional, pero no siempre fácil de leer meses después.

git rebase: reescribe tu historia para que parezca lineal

El mismo objetivo, con rebase, se ve así:

git rebase main

En vez de crear un commit de unión, Git toma cada uno de tus commits, los quita temporalmente, actualiza tu rama al último punto de main, y los vuelve a aplicar uno por uno encima. El resultado se ve como si hubieras empezado a trabajar hoy — una línea recta, sin bifurcaciones — pero por dentro son commits nuevos con identificadores distintos a los originales.

Ahí está la trampa: para Git, esos ya no son los mismos commits. Si alguien más había descargado tu rama antes del rebase, su copia y la tuya ya no coinciden, y el siguiente intento de sincronizar termina en conflictos duplicados y confusión.

La regla de oro Nunca hagas rebase de una rama que ya empujaste y que otra persona pudo haber descargado. Rebase es para historia que todavía es solo tuya.

Rebase interactivo: limpiar antes de compartir

Donde rebase brilla de verdad es limpiando tu propio desorden antes de abrir un pull request. Si hiciste cinco commits que dicen cosas como "wip", "arreglo" y "ahora sí", puedes convertirlos en uno solo, bien explicado:

git rebase -i HEAD~5

Esto abre un editor con una lista de tus últimos 5 commits. Cambia la palabra pick por squash (o solo s) en los commits que quieras fusionar con el de arriba, guarda, y Git te va a pedir un mensaje final para el commit combinado. Como esta rama todavía no la ha visto nadie más, reescribir su historia no rompe nada.

¿Y si ya empecé el rebase y me arrepentí?

Pasa. Mientras el rebase siga en curso (Git te avisa con mensajes de conflicto paso a paso), siempre puedes abortarlo y volver exactamente a como estabas:

git rebase --abort