Ambos comandos integran cambios de una rama en otra, pero de formas estructuralmente distintas, y eligen entre ellos es una de las decisiones de flujo de trabajo más discutidas en equipos que usan Git.
git rebase ¶git switch feature git rebase main
En vez de crear un commit de fusión, rebase toma cada commit
de feature que no está en main, y los vuelve a aplicar
uno por uno, en el mismo orden, sobre la punta actual de
main. El resultado son commits nuevos —con hashes
distintos, aunque el mismo contenido y mensaje— apilados
linealmente después de main. El historial final no muestra
ninguna bifurcación: parece como si feature se hubiera
escrito desde el principio a partir del main más reciente.
merge conserva la forma real en que ocurrió el trabajo,
incluyendo bifurcaciones y el punto exacto de unión. rebase
produce un historial lineal, más fácil de leer, pero que no refleja
literalmente cómo sucedieron las cosas.
merge no modifica ningún commit existente. rebase
crea commits nuevos con hashes distintos: es una forma de
reescribir historia (see Reescribir la historia).
Nunca conviene hacer rebase de una rama que otras personas ya
tienen descargada y sobre la que están trabajando, porque sus
copias locales quedarían basadas en commits que ya no existen en el
remoto. merge no tiene este riesgo.
Muchos equipos combinan ambos: usar rebase libremente en
ramas de trabajo propias, no compartidas, para mantener el
historial de la rama personal limpio y lineal antes de integrarla; y
usar merge (a menudo a través de una pull request) para la
integración final a la rama principal, dejando un registro claro de
cuándo se incorporó cada conjunto de trabajo.
La regla práctica más repetida en la comunidad de Git es: nunca reescribir (con rebase o amend) commits que ya fueron compartidos y que otra persona pudo haber usado como base de su propio trabajo.