https://medium.com/mindorks/understanding-git-merge-git-rebase-88e2afd42671
En Git, los historiales de commits se gestionan de forma distinta con los comandos git rebase y git merge, y eso afecta a cómo aparecen los commits en el historial.
git merge:
git merge, Git combina las dos ramas conservando el historial de ambas y crea un commit de merge específico. Eso significa que todos los commits de las dos ramas son visibles en el historial.git rebase:
git rebase, los commits de la rama actual se «reaplican» sobre la rama destino, lo que crea commits nuevos que corresponden a los antiguos, pero con hashes nuevos (identificadores de commit). Eso reescribe el historial para dar la impresión de que los commits se hicieron directamente sobre la rama destino.git merge: conserva el historial completo de los commits de las dos ramas, incluidos los puntos de divergencia y de fusión.git rebase: reescribe el historial eliminando los commits de divergencia y crea un historial lineal sin rastro explícito del momento en que divergieron las ramas.Es realmente importante entender las diferencias clave entre Git merge y Git rebase si quieres ser un buen gestor del control de versiones. Git merge es ideal para conservar el historial de las dos ramas y asegurarte de que todo queda a salvo. Git rebase, por su parte, es perfecto para obtener un historial de commits limpio y lineal. Sin embargo, como en todo, hay que vigilar algunos puntos, sobre todo cuando trabajas en ramas públicas. Seguir la regla de oro del rebase te ayuda a evitar conflictos delicados más adelante. 📌 Cuando decidas cuál usar, piensa simplemente en cómo trabaja tu equipo y en la visibilidad que quieres dar a tus ramas.