Cómo comprobar si un commit de Git es un commit de fusión

Introducción

En este laboratorio, aprenderás cómo determinar si un commit de Git es un commit de fusión (merge commit). Exploraremos el comando git show para examinar los detalles de un commit, centrándonos específicamente en identificar los commits padre (parent commits), que es un indicador clave de una fusión.

También aprenderás cómo usar el comando git log --merges para listar de manera eficiente solo los commits de fusión en el historial de tu repositorio. Finalmente, probaremos estos métodos en commits que no son de fusión para consolidar tu comprensión de cómo distinguir entre diferentes tipos de commits en Git.

Skills Graph

Usar git show para verificar los commits padre

En este paso, exploraremos cómo usar el comando git show para examinar los detalles de un commit, centrándonos específicamente en sus commits padre (parent commits). Comprender los commits padre es crucial para navegar por el historial de tu proyecto y entender cómo se relacionan diferentes commits entre sí.

Primero, asegúrate de estar en el directorio de tu proyecto. Abre tu terminal y navega al directorio my-time-machine:

cd ~/project/my-time-machine

Ahora, usemos git log para ver el historial de commits. Usaremos la bandera --oneline para una vista concisa:

git log --oneline

Deberías ver una salida similar a esta (tu hash de commit será diferente):

a1b2c3d (HEAD -> master) Send a message to the future

Esto muestra nuestro primer commit. Ahora, usemos git show para ver los detalles de este commit. Copia el hash de commit (la cadena corta de letras y números, como a1b2c3d) de la salida de git log y reemplaza YOUR_COMMIT_HASH en el siguiente comando:

git show YOUR_COMMIT_HASH

Por ejemplo, si tu hash de commit fuera a1b2c3d, ejecutarías:

git show a1b2c3d

La salida será bastante detallada, mostrando información sobre el commit, incluyendo el autor, la fecha, el mensaje del commit y los cambios introducidos por el commit.

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Jane Doe <[email protected]>
Date:   Mon Aug 7 10:00:00 2023 +0000

    Send a message to the future

diff --git a/message.txt b/message.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/message.txt
@@ -0,0 +1 @@
+Hello, Future Me

Para nuestro primer commit, que es el comienzo del historial de nuestro proyecto, notarás que no hay una línea "Parent" en la salida. Esto se debe a que el commit inicial no tiene padre – es la raíz del historial del proyecto.

En pasos posteriores, cuando tengamos más commits, usaremos git show nuevamente para ver cómo se muestran los commits padre y cómo enlazan el historial. Comprender este enlace es fundamental para entender cómo Git rastrea los cambios a lo largo del tiempo.

Ejecutar git log --merges para verificar

En este paso, aprenderemos sobre los commits de fusión (merge commits) y cómo usar git log --merges para ver específicamente solo este tipo de commits en el historial de nuestro proyecto. Los commits de fusión son commits especiales que combinan cambios de diferentes ramas (branches).

Actualmente, el historial de nuestro proyecto es muy simple, con solo un commit inicial. Todavía no tenemos ninguna rama ni fusiones. Vamos a confirmar esto primero ejecutando git log --merges.

Asegúrate de estar en el directorio ~/project/my-time-machine:

cd ~/project/my-time-machine

Ahora, ejecuta el comando:

git log --merges

Dado que no hemos realizado ninguna fusión, es probable que este comando no produzca ninguna salida:

¡Esto es lo esperado! El comando git log --merges está diseñado para filtrar el historial de commits y mostrar solo los commits que se crearon como resultado de fusionar una rama en otra.

Para ver este comando en acción, necesitaríamos crear una nueva rama, hacer algunos commits en esa rama y luego fusionarla de nuevo en nuestra rama principal. Exploraremos la creación de ramas y las fusiones en laboratorios futuros.

Por ahora, es importante entender que git log --merges es una herramienta poderosa para entender cuándo y cómo se combinaron diferentes líneas de desarrollo en tu proyecto. Esto es especialmente útil en entornos colaborativos donde varias personas trabajan en diferentes características simultáneamente.

Probar commits que no son de fusión

En este paso, crearemos un commit regular (un commit que no es de fusión) y luego usaremos git log para ver cómo aparece en nuestro historial en comparación con un commit de fusión (el cual aún no tenemos, pero tendremos en laboratorios futuros). Esto ayudará a consolidar tu comprensión de los diferentes tipos de commits.

Primero, hagamos un pequeño cambio en nuestro archivo message.txt. Agregaremos otra línea.

Asegúrate de estar en el directorio ~/project/my-time-machine:

cd ~/project/my-time-machine

Ahora, usa el comando echo para agregar una nueva línea al archivo:

echo "Adding another line." >> message.txt

El operador >> agrega el texto al archivo en lugar de sobrescribirlo.

Veamos el contenido del archivo:

cat message.txt

Deberías ver:

Hello, Future Me
Adding another line.

Ahora, veamos el estado de nuestro repositorio:

git status

Deberías ver que message.txt ha sido modificado:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   message.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git detecta el cambio que hicimos. Ahora, preparemos (stage) y confirmemos (commit) este cambio.

git add message.txt
git commit -m "Add a second line to message"

Deberías ver una salida que confirme el commit:

[master a1b2c3d] Add a second line to message
 1 file changed, 1 insertion(+)

Ahora, veamos nuestro historial de commits nuevamente usando git log --oneline:

git log --oneline

Deberías ver dos commits:

e4f5g6h (HEAD -> master) Add a second line to message
a1b2c3d Send a message to the future

El commit más reciente (e4f5g6h en este ejemplo, tu hash será diferente) es nuestro nuevo commit que no es de fusión. Representa un cambio único realizado directamente en la rama master.

Si tuviéramos que ejecutar git log --merges nuevamente, aún no mostraría ninguna salida porque ninguno de estos commits es un commit de fusión.

Comprender la diferencia entre commits regulares y commits de fusión es importante para interpretar el historial de tu proyecto y colaborar de manera efectiva con otros. Los commits regulares representan un progreso lineal en una sola línea de desarrollo, mientras que los commits de fusión representan la integración de cambios de diferentes líneas.

Resumen

En este laboratorio, aprendimos cómo identificar los commits de fusión (merge commits) en Git. Comenzamos utilizando el comando git show para examinar los detalles de un commit, centrándonos específicamente en la presencia o ausencia de commits padre. Vimos que el commit inicial no tiene padre, mientras que los commits posteriores mostrarán sus padre(s).

Luego exploramos el comando git log --merges, que es una forma directa de listar solo los commits de fusión en el historial del repositorio. Finalmente, probamos estos métodos en commits que no son de fusión para confirmar que se identifican correctamente como tales, consolidando nuestra comprensión de cómo distinguir los commits de fusión de los commits regulares.