En este caso, sí hubo un cambio en el historial del repositorio.
Cuando se realiza una fusión con un merge commit, Git crea un nuevo commit que une ambas ramas, y este nuevo commit recibe un hash único. Sin embargo, los commits anteriores dentro de la rama de desarrollo conservan sus hashes originales, ya que Git no los modifica, solo los incorpora en la historia de la rama principal.
Hola Justin, espero que estés bien
¡Tienes toda la razón en tu observación! Cuando realizas un merge en Git que genera un commit de fusión, efectivamente se crea un nuevo commit con un hash único que representa la combinación de las dos ramas. Este nuevo commit de merge incluye las historias de ambas ramas, pero no altera los hashes de los commits anteriores. Los commits previos mantienen sus hashes originales, ya que Git se encarga de preservar la integridad de cada commit.
Por ejemplo, si tienes una rama feature que deseas fusionar con la rama main, al realizar el merge, Git genera un nuevo commit en main que contiene las diferencias de feature y main. Este commit de merge tiene su propio hash, pero los commits individuales en feature y main permanecen inalterados.
Espero que esta explicación te haya aclarado el funcionamiento del hash en los merges de Git. ¡Espero haber ayudado y buenos estudios!