El hash de un commit en Git no cambia después de una fusión, siempre y cuando ese commit no sea modificado. Si la fusión es directa (sin conflictos), todo queda igual. Pero si hubo conflictos y los resolviste manualmente, Git crea un nuevo commit para la fusión, y ese sí tendrá un hash diferente.
El commit original donde se modificó contacto.html seguirá con su hash intacto, a menos que lo cambies directamente.
Hola Christian,
¡Tienes razón en tu observación! En Git, cada commit tiene un hash único que actúa como su identificador. Este hash se genera a partir del contenido del commit, incluyendo los cambios realizados, el autor, la fecha y el commit padre. Por lo tanto, si el contenido del commit no cambia, su hash tampoco lo hará.
Cuando realizas una fusión (merge) en Git, si no hay conflictos, Git simplemente avanza la rama de destino al commit de la rama de origen, y no se crea un nuevo commit de fusión. En este caso, los hashes de los commits anteriores permanecen inalterados.
Sin embargo, si hay conflictos durante la fusión y los resuelves manualmente, Git crea un nuevo commit de fusión para reflejar esos cambios. Este nuevo commit tendrá un hash diferente porque su contenido es diferente (incluye las resoluciones de los conflictos).
En tu ejemplo, el commit original donde modificaste contacto.html mantendrá su hash intacto a menos que realices cambios adicionales en ese commit específico.
Espero haber aclarado tu duda. ¡Espero haber ayudado y buenos estudios!