Hash Merge | Git y GitHub: repositorio, commit y versiones | Alura Latam

No.

El hash de un commit en Git nunca cambia después de haber sido creado, porque el hash (SHA-1) es una “huella digital” única calculada a partir de:

El contenido de los archivos en ese commit.

El autor, fecha y mensaje.

El commit padre (historial).

Entonces:

Cuando usas git log --oneline en la rama desarrollo, el commit con el cambio en contacto.html tendrá un hash específico.

Si luego haces un merge hacia otra rama (por ejemplo main), el commit original mantiene su hash.

Lo que sí se crea es un nuevo commit de fusión (merge commit) con su propio hash, que registra la unión de ambas ramas.

En otras palabras:
El hash del commit de contacto.html no cambia. Solo aparece un nuevo commit de merge con su propio hash en la rama donde hiciste la fusión.

¡Hola David, espero que estés bien!

Entiendo tu actividad sobre cómo funcionan los hashes de los commits en Git, especialmente después de realizar un merge. Estás en lo correcto al decir que el hash de un commit en Git nunca cambia una vez que ha sido creado. Esto se debe a que el hash es una representación única de ese commit específico, basada en su contenido, autor, fecha, mensaje y su commit padre.

Cuando realizas un merge, como mencionaste, se crea un nuevo commit de merge con su propio hash. Este nuevo commit de merge no altera el hash del commit original (en tu caso, el commit que modificó el archivo contacto.html).

Por ejemplo, imagina que tienes un commit en la rama desarrollo con el hash abc123 que modifica contacto.html. Cuando haces un merge de desarrollo a main, el commit abc123 mantiene su hash. Sin embargo, se genera un nuevo commit de merge en main con un hash diferente, digamos def456, que representa la fusión de las dos ramas.

Espero que esto aclare tu duda. ¡Espero haber ayudado y buenos estudios!