Ver el historial de Git con log, show y diff

docs.scrimba.com

Digamos que abres weather-app una mañana de lunes y no recuerdas exactamente qué implementaste el viernes. O un compañero te pregunta por qué cambió la conversión de temperatura la semana pasada, y quieres la respuesta real en lugar de una suposición. El ciclo de commit cubre cómo se guarda un commit. Este capítulo cubre leer ese historial nuevamente: qué pasó, quién lo hizo y cuándo. El comando para eso es git log, y aquí está todo lo que imprime en un proyecto pequeño:

$ git log
commit 4f2a1c9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c
Author: Priya Nair <[email protected]m>
Date:   Tue Jul 14 09:12:03 2026 +0100

    Corregir conversión de temperatura en fórmula Celsius a Fahrenheit

commit 5f3d8b21a90e7c6d5b4a3f2e1d0c9b8a7f6e5d4c
Author: Kwame Boateng <[email protected]m>
Date:   Mon Jul 13 16:45:22 2026 +0100

    Agregar pronóstico de cinco días al panel de control

commit 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
Author: Kwame Boateng <[email protected]m>
Date:   Mon Jul 13 11:03:47 2026 +0100

    Configurar estructura del proyecto

Un comando, y toda la historia del proyecto está ahí: tres commits, el más reciente primero, cada uno con quién lo escribió, cuándo y por qué.

Leer el registro con git log

git log retrocede a través de cada commit accesible desde donde estés, primero el más reciente. Cada entrada muestra cuatro cosas: un hash (la larga cadena de letras y números que identifica ese commit exacto), el autor, la fecha y el mensaje que escribió su autor.

Un commit es todas esas cuatro cosas juntas: una instantánea de cada archivo rastreado en ese momento, el mensaje que describe el cambio, quién lo hizo y un vínculo al commit que vino justo antes, su commit padre. Ese vínculo padre es lo que convierte un montón de instantáneas separadas en una línea de tiempo real. Lee git log de arriba a abajo y estarás leyendo esa línea de tiempo hacia atrás, del presente al inicio.

El hash parece intimidante al principio, pero rara vez necesitas la cosa completa. 4f2a1c9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c y 4f2a1c9 apuntan al mismo commit. Git solo necesita suficiente del hash para diferenciarlo de todos los otros commits en el repositorio, y los primeros siete u ocho caracteres casi siempre son suficientes. Verás la forma corta en todas partes, incluyendo los comandos en el resto de este capítulo.

La salida predeterminada de git log es exhaustiva pero larga: tres commits ya ocuparon toda tu terminal. Algunas formas la hacen más útil en el día a día.

$ git log --oneline
4f2a1c9 Corregir conversión de temperatura en fórmula Celsius a Fahrenheit
5f3d8b2 Agregar pronóstico de cinco días al panel de control
1a2b3c4 Configurar estructura del proyecto

--oneline colapsa cada commit a su hash corto y mensaje, una línea por commit, que es la forma que usarás la mayoría del tiempo. --graph dibuja la forma del historial al lado del registro como un conjunto de líneas y puntos. En un proyecto sin ramas todavía dibuja una línea recta simple, pero mantenlo en tus dedos desde el inicio: el momento en que aparecen las ramas (el próximo capítulo) es exactamente cuando esa imagen comienza a dar sus frutos.

También puedes filtrar el registro en lugar de desplazarte a través de él. git log --author="Kwame" muestra solo los commits escritos por Kwame, útil cuando quieres ver el trabajo de una persona en un proyecto compartido. git log -- src/index.js muestra solo los commits que tocaron ese archivo específico, ignorando todo lo que nunca se acercó a él:

$ git log --oneline -- src/index.js
4f2a1c9 Corregir conversión de temperatura en fórmula Celsius a Fahrenheit
1a2b3c4 Configurar estructura del proyecto

Ese segundo commit, el del pronóstico, nunca tocó src/index.js, así que no aparece. Ambos filtros se combinan limpiamente con --oneline.

Los filtros anteriores responden "qué commits tocaron este archivo". La pregunta que realmente te envía al historial en un mal día es más precisa: ¿cuándo apareció o desapareció este fragmento de código exacto? Para eso sirve git log -S, conocido como el pico. Dale una cadena y mantiene solo los commits donde el número de ocurrencias de esa cadena cambió, lo que significa los commits que la agregaron o removieron:

$ git log --oneline -S "showLoadingSpinner"
7d1e8c3 Agregar indicador de carga mientras se carga el pronóstico

Un commit, de todo el historial: el momento en que esa llamada entró en la base de código. Esta es la forma más rápida de responder "cuándo se introdujo esta línea de error" sin verificar nada. La regla de conteo tiene una consecuencia que vale la pena saber: un commit que solo mueve la línea dentro de un archivo deja el recuento de ocurrencias sin cambios, así que -S lo omite. Cuando quieres cada commit cuyo diff tan solo toque el texto, movimientos incluidos, usa git log -G con una expresión regular en su lugar. Alcanza por -S primero; es la herramienta más afilada para la pregunta que usualmente tienes.

JunoLeer el registrogit log enumera cada commit, el más reciente primero, con su hash, autor, fecha y mensaje. Un commit es esa instantánea más su mensaje más un vínculo al commit anterior. Casi nunca necesitas el hash completo, los primeros caracteres son suficientes para que Git sepa exactamente cuál commit quieres decir.

JunoLeer el registrogit log --oneline es la forma que usarás diariamente, una línea por commit. Agrega --author o un -- path al final para filtrar el trabajo de una persona o el historial de un archivo, y alcanza por --graph una vez que las ramas entren en la imagen.

JunoLeer el registro El hash de cada commit es una huella digital de su propio contenido más el hash de su padre, así que dos commits nunca colisionan accidentalmente y un prefijo corto es seguro de escribir. Y cuando la pregunta es "cuándo aparició o desapareció esta línea", git log -S "texto" recorre todo el historial por ti y mantiene solo los commits que la agregaron o removieron. Entre eso y el vínculo padre, este capítulo es la mayor parte de mi kit de depuración.

Inspeccionar un commit con git show

git log te dice que un commit sucedió. git show <hash> te dice exactamente qué hizo:

$ git show 4f2a1c9
commit 4f2a1c9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c
Author: Priya Nair <[email protected]m>
Date:   Tue Jul 14 09:12:03 2026 +0100

    Corregir conversión de temperatura en fórmula Celsius a Fahrenheit

diff --git a/src/index.js b/src/index.js
index 3f2c1a9..7b8e2d4 100644
--- a/src/index.js
+++ b/src/index.js
@@ -12,7 +12,7 @@ function celsiusToFahrenheit(celsius) {
-  return celsius * (9 / 5 + 32)
+  return (celsius * 9) / 5 + 32

La mitad superior es los mismos metadatos que git log muestra. Debajo está el cambio real: una línea que comienza con - es una línea que el commit removió, una línea que comienza con + es una línea que agregó, y las líneas sin marcar son contexto que se mantuvo igual. Aquí se lee claramente: la línea antigua agrupó 32 dentro de los paréntesis, así que se agregó antes de que la multiplicación sucediera. La corrección reagrupa los paréntesis alrededor de celsius * 9 para que 32 se agregue al final, el error de precedencia de operadores que describe el mensaje de Priya.

Agrega una ruta para ver solo parte de un commit más grande: git show 4f2a1c9 -- src/index.js muestra solo la porción de ese archivo del cambio, lo que importa una vez que un único commit toca varios archivos y solo te interesa uno de ellos.

JunoInspeccionar un commitgit show <hash> muestra un commit en su totalidad: quién lo hizo, cuándo y las líneas reales que cambió. Las líneas removidas comienzan con un signo menos, las líneas agregadas comienzan con un signo más. Es la forma más rápida de responder "qué hizo realmente este commit".

JunoInspeccionar un commitgit show <hash> te da los metadatos y el diff completo para un commit. Señálalo a una ruta específica también, git show <hash> -- path/to/file, cuando un commit tocó varios archivos y solo necesitas la porción de un archivo.

JunoInspeccionar un commitgit show está comparando la instantánea guardada de un commit contra la de su padre, e imprimiendo solo las líneas que difieren. Una vez que comienzas a leer diffs de esta manera, un commit deja de ser una caja misteriosa y comienza a ser dos instantáneas con una diferencia entre ellas.

Qué muestra git diff y la trampa que casi todos enfrentan

git log y git show leen el historial comprometido. git diff lee lo que no se ha comprometido aún: los cambios en tu directorio de trabajo en este momento, comparados contra tu último commit.

$ git diff
diff --git a/README.md b/README.md
index 1c2d3e4..9f8a7b6 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # weather-app
+Panel de control meteorológico de cinco días construido con JavaScript vanilla.

Ese es el cambio que hiciste a README.md, mostrado antes de haber preparado o comprometido nada. Aquí está la parte que atrapa a casi todos en su primera semana: ejecuta git add . para preparar ese mismo cambio, luego ejecuta git diff nuevamente, y no muestra nada en absoluto.

$ git add .
$ git diff

Nada impreso. El cambio no desapareció, y nada salió mal. git diff simple compara tu directorio de trabajo contra el área de preparación, y una vez que has preparado todo, esos dos ahora coinciden, así que no hay diferencia que mostrar ahí. Para ver los cambios esperando en el área de preparación, usa git diff --staged en su lugar.

$ git diff --staged
diff --git a/README.md b/README.md
index 1c2d3e4..9f8a7b6 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # weather-app
+Panel de control meteorológico de cinco días construido con JavaScript vanilla.

El mismo cambio, ahora visible, porque --staged compara el área de preparación contra tu último commit en su lugar.

git diff simple y git diff --staged están respondiendo dos preguntas diferentes, y ayuda nombrarlas con precisión. git diff simple compara tu directorio de trabajo al área de preparación: muestra cambios que has hecho pero aún no has preparado. git diff --staged compara el área de preparación a tu último commit: muestra exactamente qué iría a tu próximo commit si ejecutaras git commit en este momento. Ninguno muestra ambos a la vez, que es exactamente por qué un cambio completamente preparado hace que git diff simple se quede en silencio. Algunas veces verás --cached en tutoriales y documentos más antiguos; significa lo mismo que --staged.

Ejecutar ambos antes de que hagas commit es una buena costumbre: git diff simple confirma que nada importante quedó sin preparar, y git diff --staged confirma exactamente qué está a punto de ser guardado.

JunoVer qué cambiógit diff muestra cambios en tu directorio de trabajo que aún no están preparados. Una vez que preparas todo con git add, git diff simple se queda en silencio. Eso es esperado, tus cambios siguen ahí. Usa git diff --staged para ver qué espera ser comprometido.

JunoVer qué cambiógit diff simple es directorio de trabajo contra área de preparación, git diff --staged es área de preparación contra tu último commit, dos comparaciones diferentes. Ejecutar ambos antes de que hagas commit te dice qué está sin preparar y qué está a punto de ser guardado. Material más antiguo a veces dice --cached, mismo indicador, nombre diferente.

JunoVer qué cambió Ambos diffs son la misma operación aplicada a diferentes pares de instantáneas: árbol de trabajo contra área de preparación, o área de preparación contra el último commit. Nombrar cuáles dos cosas estás comparando es el truco completo para nunca confundirte por un git diff vacío nuevamente.

Por qué el historial de Git forma un gráfo

Cada commit que has visto hasta ahora apunta a exactamente un padre, y leer git log de arriba a abajo se ha sentido como leer una línea recta. Eso se sostiene para un proyecto en solitario trabajando en una línea de trabajo. Deja de sostenerse el momento en que las ramas y fusiones entran en la imagen, cubierto a continuación en Ramas, porque el historial real de un proyecto puede dividirse en líneas separadas y volver a juntarse.

Para esto sirve el indicador --graph de antes. En weather-app en este momento dibuja una sola columna, porque solo hay una línea de commits para dibujar. Una vez que una rama se bifurca y más tarde se fusiona de nuevo, --graph comienza a dibujar la bifurcación y la reunión como columnas separadas que se encuentran, lo que es mucho más fácil de leer que intentar imaginarlo desde una lista plana de hashes.

Ejecuta git show en un commit de fusión y, de forma predeterminada, imprime solo los metadatos: ningún diff en absoluto. Agrega -m e imprime un diff separado para cada padre a su vez. Ambos comportamientos se remontan a la misma forma: el historial de Git es un DAG, un gráfo acíclico dirigido. "Dirigido" significa que cada vínculo apunta en una dirección, un commit hacia su padre, nunca hacia adelante. "Acíclico" significa que esos vínculos nunca hacen un bucle, así que recorrerlos siempre se mueve hacia el inicio del proyecto, nunca hacia un commit que ya pasaste. Un commit normal tiene exactamente un padre, que es por qué el registro de un proyecto en solitario se lee como una línea recta. Un commit de fusión es la excepción: lleva dos hashes padre en lugar de uno, y con dos padres, git show simple no tiene un "el diff" único para imprimir hasta que -m le diga que compare contra cada padre por separado. Las ramas y la fusión, los próximos dos capítulos, se construyen directamente en este mismo gráfo.

JunoEl historial como un gráfo En este momento cada commit que has visto apunta a un padre, así que el registro se lee como una línea recta. Eso cambia una vez que las ramas se bifurcan y se fusionan nuevamente, que conocerás a continuación. La forma debajo, commits vinculados al commit antes de ellos, es lo que hace posible cualquiera de eso.

JunoEl historial como un gráfo Una línea en solitario de commits se ve recta porque cada uno tiene un padre único. El indicador --graph es lo que hace visible la forma una vez que comienza el ramificación, dibujando bifurcaciones y fusiones en lugar de una lista plana. Mantenlo en tu kit de herramientas incluso antes de que lo necesites.

JunoEl historial como un gráfo El historial de Git es un gráfo acíclico dirigido: los punteros padre solo apuntan hacia atrás y nunca hacen un bucle. Un commit de fusión es el único lugar donde un commit obtiene dos padres en lugar de uno, que es por qué git show simple no imprime un diff ahí hasta que agregues -m para elegir un padre. Las ramas y la fusión te enseñan el resto de este mismo gráfo, desde diferentes ángulos.