Leer el historial

La pregunta que justifica todo lo anterior

Un martes cualquiera alguien pregunta: «¿desde cuándo la plantilla de cotización cobra el domicilio aparte, y quién lo decidió?».

Sin historial, eso se responde preguntando por ahí y esperando que alguien se acuerde. Con historial es un comando, y la respuesta trae fecha, autor y el motivo que se escribió ese día.

El historial, en una línea por commit

git log --oneline

Resultado

a91c4e2 fix: el domicilio se cobra aparte en la cotizacion de servicios
7d3b8f1 docs: condiciones de pago y tiempo de entrega
4c5e0a9 feat: plantilla de cotizacion de hardware
8f2a1c9 Plantillas de cotizacion de servicios y hardware

Cuatro formas de mirar lo mismo

git log tiene muchas opciones, pero con cuatro te defiendes en el 95% de los casos. No hay que memorizarlas: se copian y quedan.

Las cuatro que se usan de verdad

# Compacto, con el dibujo de las ramas
git log --oneline --graph --all

# Solo lo que toco un archivo concreto
git log --oneline -- cotizacion-servicios.md

# Los ultimos cinco, con autor y fecha
git log -5 --pretty=format:"%h  %an  %ad  %s" --date=short

# Buscar por texto del mensaje
git log --oneline --grep="domicilio"

Resultado

a91c4e2  Ana Gomez  2026-09-04  fix: el domicilio se cobra aparte en la cotizacion de servicios

Ver el cambio, no solo el título

El log te dice qué commits hay. Para ver qué cambió dentro de uno hay dos comandos, y la diferencia entre ellos es la que hay entre «lo que ya está guardado» y «lo que todavía no».

show y diff: cuál usar

git show

Enseña un commit ya guardado: su mensaje, su autor y las líneas que cambió.

git show a91c4e2

Sin identificador muestra el último. Es la respuesta a «¿qué hice ayer?».

git diff

Enseña lo que has cambiado y todavía no está en ningún commit.

git diff compara tu carpeta con lo último preparado; git diff --staged compara lo preparado con el último commit.

Comparar dos puntos

git diff 4c5e0a9 a91c4e2 muestra todo lo que cambió entre esos dos commits, aunque haya diez en medio.

Es lo que se usa para responder «¿qué le pasó a esto entre marzo y hoy?».

Cómo se lee una diferencia

--- a/cotizacion-servicios.md
+++ b/cotizacion-servicios.md
@@ -12,7 +12,8 @@
 ## Condiciones
 
-El valor incluye el desplazamiento dentro de la ciudad.
+El valor NO incluye desplazamiento.
+El domicilio se cobra aparte segun la zona.
 
 El tiempo de respuesta es de 24 horas habiles.

Se lee solo en cuanto sabes dos símbolos: la línea con - es como estaba y la línea con + es como quedó. Lo que no lleva símbolo es contexto, para que sepas en qué parte del archivo estás. El @@ -12,7 +12,8 @@ dice el número de línea.

Y ahora, la parte que depende de ti

Todo lo anterior funciona igual de bien para todo el mundo. Lo que cambia -y mucho- es si el historial dice algo cuando lo abres.

A Git le da exactamente igual lo que escribas en el mensaje. Acepta asdf. El mensaje no es para Git: es para la persona que va a leer ese historial dentro de un año, que estadísticamente eres tú y no te vas a acordar de nada.

El mismo trabajo, contado de dos maneras

# Un historial que no responde ninguna pregunta
3a1f9c2 cambios
9b7e4d0 arreglos varios
1c8a5b3 actualizacion
6f2d7e8 ya quedo

# El mismo trabajo, legible
a91c4e2 fix: el domicilio se cobra aparte en la cotizacion de servicios
7d3b8f1 docs: condiciones de pago y tiempo de entrega
4c5e0a9 feat: plantilla de cotizacion de hardware
2e9f1a7 fix: el IVA se calculaba sobre el valor con descuento ya aplicado

La regla práctica: el mensaje describe qué cambió y por qué, no qué archivo tocaste -eso ya lo sabe Git-. «Actualicé el documento» no aporta nada; «el IVA se calculaba sobre el valor con descuento ya aplicado» explica un error que alguien podría volver a cometer.

Una convención que se usa mucho

Muchos equipos empiezan el mensaje con una palabra que dice de qué tipo de cambio se trata. No es una regla de Git -es una costumbre-, pero convierte el historial en algo que se puede filtrar y leer de un vistazo.

Los cinco prefijos más extendidos

Adivina qué tipo de cambio marca cada uno antes de voltear.

Un mensaje que sirve, en tres decisiones

Una sola idea por commit
Si al escribir el mensaje te sale un «y» -«arreglo el IVA y agrego la plantilla nueva»- son dos commits. Se separan con git add, que para eso existe.

El día que haya que deshacer uno de los dos, lo vas a agradecer.
La primera línea, corta y en presente
Unos 50 caracteres, sin punto final, describiendo el efecto: «el domicilio se cobra aparte», no «cambié el archivo de cotización».
Si hace falta el porqué, va debajo
Deja una línea en blanco y escribe los párrafos que necesites. Ahí va el motivo, la decisión que hubo detrás o el número del ticket.

Se hace con git commit sin -m: Git abre el editor para que escribas título y cuerpo.

Dos preguntas que aparecen aquí

¿Puedo corregir el mensaje del último commit?

Sí: git commit --amend -m "mensaje corregido".

Con una advertencia importante: eso reemplaza el commit por uno nuevo con otro identificador. Mientras no lo hayas compartido es inofensivo; si ya lo subiste, le estás cambiando la historia a los demás. Lo verás en la lección 5.

¿Quién escribió esta línea, y en qué commit?

git blame archivo.md pone, delante de cada línea, el commit y el autor que la dejó así.

El nombre suena a buscar culpables y casi siempre se usa al revés: para encontrar el commit y leer por qué se hizo ese cambio.

Compruébalo tú mismo

Cambiaste un archivo pero aún no hiciste commit. ¿Qué comando te muestra ese cambio?

En una diferencia, ¿qué significa una línea que empieza por -?

¿Cuál de estos mensajes de commit sirve de verdad?

Lo que sigue

Hasta aquí has trabajado en una sola línea de tiempo. En la siguiente lección vas a abrir varias a la vez: probar un cambio grande sin tocar lo que ya funciona, que es para lo que existen las ramas.