Hasta ahora hemos mirado siempre hacia delante: crear el repositorio, preparar cambios, confirmarlos, revisar el diff antes de registrarlo. Esta lección cambia el sentido de la mirada. Vamos a consultar el pasado.

Y aquí está el verdadero valor de Git. Guardar versiones no sirve de gran cosa si después no puedes responder a preguntas como: ¿cuándo se introdujo esta función? ¿Quién tocó estilos.css la semana pasada y por qué? ¿En qué confirmación desapareció aquella línea que juraría haber escrito? ¿Qué se hizo en el proyecto entre el lunes y el jueves?

git log responde a todas ellas, pero su salida por defecto es solo la punta del iceberg. Es un comando enormemente configurable: formatos compactos, gráficos, resúmenes por fichero, plantillas propias y una batería de filtros que permiten localizar una confirmación entre miles. En esta lección lo recorreremos entero, junto con git show para inspeccionar una confirmación concreta y las distintas formas de referirse a un commit, que hemos ido usando de pasada (HEAD, HEAD~1) sin explicarlas del todo.

1. El repositorio de Bruno: nuestro banco de pruebas
2. git log por defecto
3. Formatos compactos: --oneline y --graph
4. Ver qué cambió: --stat y --patch
5. Formatos personalizados con --pretty=format:
6. Filtrar el historial: cantidad, fechas, autor y mensaje
7. Filtrar por ruta y la búsqueda "pickaxe" (-S y -G)
8. git show: inspeccionar una confirmación
9. Cómo referirse a una confirmación
10. Combinaciones útiles para el día a día

Han pasado unos días desde que Bruno clonó el proyecto. Ana ya tenía cuatro confirmaciones cuando él llegó, y desde entonces Bruno ha hecho tres más en su propia copia. Este es el historial que tiene en su MacBook:

Siete confirmaciones: las cuatro de Ana que llegaron con el clon y las tres que ha hecho Bruno en local. Fíjate en (origin/main): marca el punto en el que estaba el servidor cuando Bruno clonó. Sus tres confirmaciones están por delante de esa marca porque todavía no las ha enviado; eso es materia del módulo 4.

Este historial mixto nos vendrá muy bien: tiene dos autores, fechas distintas y cambios sobre ficheros distintos, que es justo lo que necesitamos para practicar los filtros.

(La salida continúa; se sale del paginador con q.)

Cada entrada tiene cuatro elementos:

Un par de precisiones importantes:

• El orden es cronológico inverso: lo más reciente arriba. Es lo que quieres el 95 % de las veces. Se invierte con --reverse.
• Author y Committer son campos distintos. Recuerda del modelo de datos que un commit guarda ambos. Normalmente coinciden y git log solo muestra el primero; se separan cuando alguien aplica un parche ajeno o al hacer rebase. Para ver los dos:

• git log solo muestra el historial alcanzable desde donde estás. Por defecto parte de HEAD y va siguiendo los enlaces a los padres. Confirmaciones que existan en otras ramas no aparecen salvo que las pidas explícitamente o uses --all.

Una línea por confirmación: hash abreviado, referencias que apuntan ahí y primera línea del mensaje. Es el formato que más se usa, y explica por qué esa primera línea debe funcionar por sí sola: en esta vista es lo único que se ve.

--oneline es en realidad un atajo de --pretty=oneline --abbrev-commit.

Dibuja el grafo de confirmaciones con caracteres de texto:

Con una sola línea de desarrollo, el gráfico es una columna de asteriscos y no aporta gran cosa. Su valor aparece cuando hay ramas y fusiones, donde muestra las bifurcaciones y los puntos de unión:

Ese es el aspecto que tendrá el historial del equipo a partir del módulo 3. Para ver el grafo de todas las ramas, no solo la actual:

--decorate muestra las referencias (ramas, etiquetas, HEAD) junto a cada confirmación. En Git moderno está activado por defecto en el terminal, pero conviene conocerlo.

Es la vista más útil para hacerse una idea rápida del tamaño y el alcance de cada cambio sin leer el código. Variantes:

Muestra el historial con el diff de cada confirmación, en el formato unified diff que aprendiste a leer en la lección anterior. Es la forma más completa de revisar trabajo, y también la más larga: úsala siempre con un límite (-1, -5) o combinada con un filtro.

Una combinación especialmente valiosa:

Muestra la evolución completa de un solo fichero, confirmación a confirmación, con el diff de cada una. Es como ver una película del fichero desde su nacimiento.

Cuando ninguno de los formatos predefinidos encaja, puedes diseñar el tuyo con una plantilla:

Los marcadores empiezan por %. Estos son los que de verdad se usan:

Los marcadores %C... controlan el color y hacen la salida mucho más legible:

Colores disponibles: red, green, yellow, blue, magenta, cyan, white, y %C(auto) para que Git decida. %C(reset) vuelve al color normal, y %C(bold …) da negrita.

Esta plantilla es un clásico y merece guardarse como alias:

Los alias se guardan en el ~/.gitconfig con el mecanismo que vimos en Configurando Git, y se tratan a fondo en Git Log y Alias.

En un proyecto de dos años, git log devuelve miles de entradas. Los filtros son lo que convierte el comando en una herramienta de búsqueda.

Git acepta expresiones en lenguaje natural (en inglés), lo cual es muy cómodo:

El valor es una expresión regular que se busca tanto en el nombre como en el correo, así que basta con un fragmento:

Y el filtro simétrico para el confirmador:

También es una expresión regular, y por defecto distingue mayúsculas. Para ignorarlas:

Varios --grep se combinan con O lógico por defecto; --all-match los convierte en Y:

Y ojo con esto: cuando combinas filtros de distinto tipo, se aplican con Y lógico:

Confirmaciones de Bruno, del 30 de julio en adelante, cuyo mensaje contenga "estilo". Una sola.

Solo las confirmaciones que modificaron ese fichero. Igual que en git diff, el -- separa opciones de rutas y es obligatorio cuando el nombre podría confundirse con una rama.

Acepta directorios y patrones:

Combinado con -p, es la mejor forma de entender cómo llegó un fichero a ser lo que es:

--follow sigue el fichero a través de renombrados. Sin él, el historial se cortaría en el momento en que el fichero cambió de nombre. Solo funciona con un fichero a la vez.

Aquí llega una de las capacidades más útiles y menos conocidas de Git. -S busca las confirmaciones en las que cambió el número de apariciones de una cadena. En la práctica: cuándo se introdujo o se eliminó ese texto.

Una sola confirmación: aquella en la que apareció la función. Si más adelante alguien la borrara, esa confirmación también saldría.

Compara con --grep, que es una cosa completamente distinta:

El caso de uso estrella de -S es este: encuentras en el código una línea rara, quieres saber por qué está ahí, y git blame solo te dice quién la tocó por última vez. Con -S encuentras la confirmación original que la introdujo, con su mensaje explicativo.

Muestra la confirmación donde apareció esa declaración CSS, con su diff. Búsqueda quirúrgica.

Para verlo con más detalle:

La diferencia con -S es sutil pero importante:

• -S "texto" encuentra los commits donde cambió el número de veces que aparece ese texto. Si mueves una línea de sitio dentro del mismo fichero, el número no cambia y -S no la encuentra.
• -G "regex" encuentra todos los commits cuyo diff contiene alguna línea añadida o eliminada que case con la expresión. Un movimiento sí aparece.

Regla práctica: -S para "¿cuándo se introdujo esto?"; -G para "¿qué commits tocaron algo parecido a esto?".

Ambos aceptan --pickaxe-regex y se combinan con todos los demás filtros:

Cuando ya has localizado la confirmación que te interesa, git show te la enseña entera:

Metadatos y diff en una sola vista. Es equivalente a git log -p -1 <commit>, pero más directo.

git show es más versátil de lo que parece, porque acepta cualquier objeto de Git:

La sintaxis <commit>:<ruta> es especialmente útil. Ya la usamos en el módulo anterior para comprobar qué versión de un fichero había quedado registrada. Sirve, por ejemplo, para recuperar una versión antigua sin tocar nada más:

Y combinada con -s y un formato, git show sirve para extraer datos concretos:

Llevamos usando HEAD, HEAD~1 y hashes sin haber sistematizado la notación. Vamos a cerrarla, porque aparece en prácticamente todos los comandos de Git.

Basta con escribir un prefijo inequívoco. Git necesita al menos 4 caracteres y usa 7 por defecto al mostrar. En repositorios muy grandes puede hacer falta alguno más; si el prefijo es ambiguo, Git te avisa:

Estos dos son los que confunden, y la diferencia solo importa cuando hay fusiones (commits con más de un padre):

En resumen:

• ~ recorre generaciones hacia atrás por la línea principal. ~3 = tres pasos atrás.
• ^ elige entre los padres de un mismo commit. ^2 = el segundo padre.

En un historial lineal como el de Bruno, HEAD~2 y HEAD^^ son exactamente lo mismo:

El diagrama lo aclara:

Las flechas apuntan hacia atrás porque así es como funciona Git: cada commit conoce a su padre, no a sus hijos. Por eso es fácil recorrer el historial hacia el pasado y no existe una notación sencilla para ir hacia el futuro.

Y cuando haya fusiones (módulo 3), ^ cobrará sentido:

Dos puntos definen un rango de confirmaciones:

Se lee como "las confirmaciones alcanzables desde c5d9b1e pero no desde 8b6d3c2". Es decir: lo que hay después de 8b6d3c2 hasta c5d9b1e incluido. Fíjate en que el extremo izquierdo queda fuera.

Formas muy usadas:

Ese penúltimo es exactamente lo que Bruno tiene pendiente de enviar:

Sus tres confirmaciones locales. Todo esto se desarrollará en el módulo 4.

git rev-parse traduce cualquier notación a un hash completo, y es la forma de salir de dudas:

Un recetario de consultas que resuelven preguntas reales:

Y una advertencia práctica: git log abre un paginador. Se recorre con las flechas o la barra espaciadora, se busca con /texto y se sale con q. Si prefieres la salida directa:

• Confundir --grep con -S. --grep busca en el mensaje de la confirmación; -S busca en el contenido de los ficheros. Son preguntas completamente distintas y es el error más frecuente al buscar en el historial.
• Olvidar el -- antes de una ruta. git log estilos.css funciona si no hay ambigüedad, pero git log main interpretará main como una rama. Pon -- siempre que puedas dudar.
• Esperar que git log muestre todas las ramas. Por defecto solo recorre el historial alcanzable desde HEAD. Para verlo todo, --all.
• Interpretar mal los rangos a..b. El extremo izquierdo no se incluye. git log HEAD~3..HEAD devuelve tres confirmaciones, no cuatro.
• Usar ~ cuando se quiere ^. En un historial lineal son intercambiables, pero en una fusión HEAD^2 (el segundo padre) y HEAD~2 (dos generaciones atrás) apuntan a sitios distintos.
• Quedarse atrapado en el paginador. Se sale con q. Es una de las primeras frustraciones de todo el mundo con Git.
• Buscar en git log -p a ojo. Si buscas dónde apareció un texto concreto, -S te lo da en un comando en lugar de hacerte leer cien diffs.
• No usar --follow al mirar el historial de un fichero renombrado. Verás un historial que "empieza" en el renombrado y concluirás erróneamente que el fichero es reciente.
• Consejo: define el alias lg del apartado 5. Lo usarás a diario y hace el historial mucho más legible.
• Consejo: git shortlog -sn es la forma más rápida de saber quién trabaja en un proyecto que acabas de clonar. Y git log --oneline -20 te da el pulso de lo que se está haciendo ahora mismo.
• Consejo: si quieres exportar el historial para un informe, --pretty=format: combinado con --date=short produce líneas fáciles de procesar con cualquier hoja de cálculo.

Partiendo del historial de Bruno tal como aparece en el apartado 1:

Escribe el comando exacto para cada consulta y predice su salida:

1. Las tres últimas confirmaciones, en una línea cada una.
2. Todas las confirmaciones de Ana.
3. Todo lo hecho entre el 23 y el 27 de julio, ambos incluidos.
4. Las confirmaciones que tocaron estilos.css.
5. Las confirmaciones cuyo mensaje contenga "tarea", sin distinguir mayúsculas.
6. Un listado con formato hash | fecha corta | autor | asunto.
7. Cuántas confirmaciones hay en total y cuántas ha hecho cada persona.
8. El contenido de README.md tal como estaba en 4e7f2a9.

Crea un repositorio con un historial en el que una línea aparece, se mueve y desaparece:

1. ¿Qué devuelve git log --oneline -S "DEPURACION"? Explica por qué aparece cada confirmación y por qué falta alguna.
2. ¿Qué devuelve git log --oneline -G "DEPURACION"? Compara con el resultado anterior y explica la diferencia.
3. ¿Qué devuelve git log --oneline --grep="DEPURACION"? ¿Y --grep="depuración"?
4. Escribe el comando que muestre el diff de la confirmación exacta en que se eliminó la traza.
5. Redacta en una frase la regla que te permitirá elegir entre -S, -G y --grep en el futuro.

Sobre el repositorio del ejercicio 2 (cuatro confirmaciones, historial lineal):

1. Escribe cuatro formas distintas de referirte a la segunda confirmación del historial (la que añadió la traza).
2. Comprueba con git rev-parse que HEAD~2 y HEAD^^ apuntan al mismo objeto.
3. Muestra el contenido de app.js tal como estaba en la primera confirmación, sin modificar tu directorio de trabajo.
4. Muestra únicamente los mensajes de las dos últimas confirmaciones, sin diff.
5. Usa un rango para listar solo las dos últimas confirmaciones y explica por qué HEAD~2..HEAD devuelve dos y no tres.
6. Averigua qué ficheros modificó cada una de las cuatro confirmaciones con un solo comando.

Solución al Ejercicio 1

1. Las tres últimas:

2. Las de Ana:

3. Entre el 23 y el 27, ambos incluidos:

Atención al detalle: --until="2026-07-27" se interpreta como las 00:00 de ese día, así que excluiría las confirmaciones del propio 27. Como aquí queremos incluir el día 27 completo, ponemos --until="2026-07-28". Es un error clásico que hace "desaparecer" confirmaciones del último día del rango.

4. Las que tocaron estilos.css:

Nota: 1a4c8d6 creó el fichero, así que en un historial real también aparecería. En el enunciado se indica que la confirmación inicial contenía los cuatro ficheros, de modo que la salida completa sería de tres entradas.

5. Mensajes con "tarea", sin distinguir mayúsculas:

Cinco de las siete. Quedan fuera c5d9b1e ("Documentar la instalación en el README") y 8b6d3c2 ("Añadir estilos base del listado"), cuyos mensajes no contienen la palabra.

6. Formato personalizado:

7. Totales:

8. El README en 4e7f2a9:

Muestra el contenido del fichero tal como estaba en esa confirmación, sin tocar el directorio de trabajo. Si quisiéramos guardarlo aparte:

Solución al Ejercicio 2

1. Con -S:

Dos confirmaciones. -S busca cambios en el número de apariciones de la cadena:

• 9b3e5d7: pasó de 0 apariciones a 1. Cambió → aparece.
• 1f4c8a2: pasó de 1 a 0. Cambió → aparece.

Falta 7a2d6f9 ("Mover la traza a la función fin y añadirla"). Y aquí está el matiz que hay que entender: en esa confirmación la traza se movió de inicio() a fin(), así que sigue apareciendo una sola vez. Como el recuento no varía (1 → 1), -S la considera irrelevante y no la muestra.

2. Con -G:

Tres confirmaciones. -G no cuenta apariciones: mira si el diff de la confirmación contiene alguna línea añadida o eliminada que case con la expresión. En 7a2d6f9 hay una línea con DEPURACION eliminada y otra añadida, así que sí aparece.

Esta es exactamente la diferencia entre ambas opciones, y el ejercicio la aísla en su forma más pura.

3. Con --grep:

Ninguna, porque --grep busca en el mensaje, y ningún mensaje contiene la palabra en mayúsculas.

Dos: las que llevan esa palabra en el mensaje. Que coincidan con el resultado de -S es pura casualidad del ejemplo; se debe a que los mensajes describen bien lo que hacen.

4. El diff de la eliminación:

O, más directo y más legible, localizar el commit y mostrarlo:

Una forma robusta de encadenarlo, sin conocer el hash de antemano:

que muestra la confirmación más reciente en la que cambió el recuento de esa cadena: precisamente la eliminación.

5. La regla:

--grep busca en el mensaje ("¿quién dijo que hizo esto?"); -S busca cuándo apareció o desapareció un texto en el código ("¿de dónde salió esta línea?"); -G busca qué confirmaciones tocaron líneas que casan con un patrón, incluidos los movimientos ("¿quién ha andado por aquí?").

Solución al Ejercicio 3

1. Cuatro formas de referirse a la segunda confirmación (con HEAD en la cuarta):

Y hay más: el hash completo, main~2, @~2… Todas resuelven al mismo objeto.

2. Comprobación:

Hashes idénticos. En un historial lineal ~n y n símbolos ^ son equivalentes, porque cada commit tiene un único padre y "elegir el primer padre" y "retroceder una generación" son la misma operación. La diferencia solo emerge en las fusiones.

3. El fichero en la primera confirmación:

git show <commit>:<ruta> lee del historial y escribe en la salida estándar. No modifica nada, a diferencia de git restore --source=..., que sí sobrescribiría el fichero del disco.

4. Solo los mensajes de las dos últimas:

O, si prefieres la vista completa sin el diff:

5. El rango:

Dos confirmaciones, no tres, porque el extremo izquierdo del rango queda excluido. a..b significa "todo lo alcanzable desde b que no lo sea desde a", y HEAD~2 es alcanzable desde sí mismo, así que se descarta. La forma de leerlo es: "lo que ha pasado después de HEAD~2".

Si quisieras incluir también HEAD~2, tendrías que escribir HEAD~3..HEAD.

6. Ficheros modificados por cada confirmación:

Las tres últimas confirmaciones modifican app.js (M) y la primera lo añade (A), lo cual es coherente: era el root-commit y el fichero no existía antes.

Con esta lección cerramos el ciclo básico de Git y el módulo 2. Recapitulando lo aprendido aquí:

• git log recorre el historial hacia atrás desde HEAD, en orden cronológico inverso, siguiendo los enlaces a los padres.
• Los formatos cambian por completo lo que ves: --oneline para la vista de trabajo, --graph para la estructura (imprescindible en cuanto haya ramas), --stat para el alcance de cada cambio y -p para el diff completo.
• --pretty=format: permite diseñar tu propia salida con marcadores como %h, %an, %ar y %s, y merece la pena guardarla como alias.
• Los filtros convierten git log en un buscador: -n por cantidad, --since/--until por fecha, --author por persona, --grep por mensaje y -- <ruta> por fichero. Filtros de distinto tipo se combinan con Y lógico.
• La búsqueda "pickaxe" es la joya escondida: -S encuentra cuándo apareció o desapareció un texto en el código, y -G qué confirmaciones tocaron líneas que casan con un patrón. No confundir ninguna de las dos con --grep, que mira el mensaje.
• git show inspecciona una confirmación concreta —metadatos y diff— y con la sintaxis <commit>:<ruta> recupera cualquier fichero tal como estaba en cualquier momento del pasado.
• Referirse a una confirmación se puede hacer por hash (completo o abreviado), por referencia simbólica (HEAD, main, origin/main, una etiqueta) o por navegación relativa: ~ retrocede generaciones y ^ elige entre padres. Los rangos a..b excluyen el extremo izquierdo.

Has recorrido el ciclo completo de trabajo con Git en solitario:

1. Crear el repositorio (git init) o unirte a uno existente (git clone).
2. Trabajar siguiendo el ciclo editar → preparar → confirmar, con git status como brújula.
3. Elegir con precisión qué entra en cada confirmación, incluso a nivel de fragmento con git add -p.
4. Revisar los cambios con git diff antes de registrarlos.
5. Consultar el pasado con git log y git show.

Con esto ya puedes usar Git de forma productiva en cualquier proyecto propio. Pero hay un problema esperando.

Fíjate en la situación real en la que están Ana y Bruno ahora mismo. Los dos han estado trabajando sobre main, cada uno en su portátil, sin coordinarse. Ana ha añadido el contador de tareas y el marcado de completadas; Bruno ha añadido el filtro de pendientes y ha tocado los mismos ficheros. Ninguno de los dos ha visto el trabajo del otro.

Cuando intenten juntar todo eso, se encontrarán con dos versiones distintas de app.js que han evolucionado por separado desde el mismo punto de partida. Y esto es solo con dos personas y una semana de trabajo: cuando Carla se incorpore desde Windows y haya tres líneas de desarrollo simultáneas, trabajar todos sobre main será insostenible.

Además, hay un problema más sutil. Ahora mismo, si Ana quiere probar una idea arriesgada, no tiene dónde hacerlo: cualquier cosa que confirme va directa a la única línea del proyecto. Y si a mitad de una tarea urgente aparece un fallo crítico, tiene que abandonar lo que está haciendo o confirmarlo a medias.

La respuesta a todo esto son las ramas, y son la característica que convirtió a Git en el estándar de la industria. En el módulo 3: Ramas y Fusión veremos qué es realmente una rama (spoiler: ya lo sabes, es un fichero con un hash dentro, como comprobamos al crear el primer commit), cómo crearlas y moverse entre ellas, cómo fusionar el trabajo de varias personas, qué estrategias usa Git para hacerlo, cómo resolver los conflictos cuando dos personas tocan la misma línea, y cómo mantener ordenado un repositorio con muchas ramas vivas.

Todo lo que has aprendido en este módulo —las tres zonas, el área de preparación, el diff, el historial— sigue siendo válido exactamente igual. Solo que a partir de ahora habrá más de una línea de trabajo a la vez.