Carla ya ha arreglado el borrado de tareas gracias a bisect. Pero mientras estaba en app.js se ha encontrado con esto:

Nadie del equipo recuerda haber escrito esa función. No está documentada, no tiene comentarios y su aspecto es el de un parche defensivo contra algo muy concreto. La tentación de borrarla es enorme: son cinco líneas que "no hacen nada".

Esa tentación es exactamente el escenario que describe la valla de Chesterton: no quites una valla del medio del campo hasta que sepas por qué la pusieron. Y en un repositorio Git siempre se puede saber, porque cada línea de cada fichero procede de un commit concreto, con su autor, su fecha y su mensaje.

La herramienta que hace esa consulta es git blame, y en esta lección vamos a exprimirla: no solo para ver quién tocó la línea por última vez, sino para atravesar el ruido —reformateos, código movido, cambios de espaciado— y llegar al commit que de verdad explica el porqué.

1. Qué es exactamente git blame
2. Leer la salida
3. Acotar: -L por líneas y por función
4. Ver más allá del ruido: -w, -M y -C
5. Viajar en el tiempo: <sha>^ y --since
6. git log -L: la evolución completa de un rango de líneas
7. Ignorar commits de formateo: --ignore-rev y .git-blame-ignore-revs
8. Resolviendo el misterio de normalizarTexto
9. Blame en la práctica: atribución, no culpa

git blame <fichero> responde a una pregunta muy concreta:

Para cada línea del fichero tal y como está ahora, ¿cuál fue el último commit que la modificó?

Conviene subrayar tres cosas de esa definición, porque los tres malentendidos más comunes salen de ahí:

• Es "el último que la tocó", no "el que la escribió". Si Ana escribió la línea en enero y Bruno le cambió una coma en junio, blame señala a Bruno. Los apartados 4 y 7 son precisamente las herramientas para atravesar ese ruido.
• Trabaja sobre el estado actual del fichero. Las líneas borradas no aparecen: si te interesan, la herramienta es git log -L (apartado 6) o el pickaxe -S de la lección 02-06.
• No calcula nada nuevo. Toda la información ya está en el modelo de datos de la lección 01-04: blame recorre el historial del fichero comparando versiones y atribuye cada línea. Es una consulta, no un metadato guardado.

Las cinco columnas, de izquierda a derecha:

Y dos marcas especiales que hay que saber leer:

• ^7d2a1f8, con acento circunflejo: la línea viene del commit más antiguo del rango analizado. Suele ser el commit inicial (boundary commit). Significa "esto es tan viejo como el propio historial que estoy mirando".
• 00000000 / "No Cometido" (Not Committed Yet en inglés): la línea está modificada en el árbol de trabajo y aún no se ha confirmado. Es tuya, ahora mismo.

Opciones de formato que ahorran mucho tiempo:

Y el que de verdad se usa a diario, porque combina lo justo:

Un detalle práctico: la salida de blame es larga y suele pasar por el paginador. Para saltar directamente a la zona que te interesa, en less basta con /normalizarTexto + Enter. Pero es mucho mejor acotar de entrada, que es lo siguiente.

Casi nunca quieres el fichero entero. -L limita el análisis a un rango:

Formas de expresar el rango, todas válidas:

La forma -L :<nombre>:<fichero> es la más cómoda y la menos conocida. Git localiza el bloque de la función usando las mismas reglas de funcname que emplea git diff para las cabeceras de los hunks (lección 02-05):

Primera pista del misterio: la función la creó Carla en febrero, y Ana añadió los dos replace en mayo. Dos commits, dos motivos posiblemente distintos.

El reconocimiento de funciones depende del lenguaje. Git trae patrones integrados para muchos (c, java, python, php, rust...). Para JavaScript, el patrón integrado javascript se activa declarándolo en .gitattributes con *.js diff=javascript. Ese fichero, y todo lo que permite configurar, es el tema de la lección 08-04; aquí basta saber que si -L :funcion: no acierta, esa es la razón.

Aquí está el verdadero valor de blame, y lo que separa el uso ingenuo del uso experto. La atribución "en bruto" miente constantemente, porque:

• Alguien reindentó el fichero → todas las líneas son suyas.
• Alguien movió una función de sitio dentro del mismo fichero → todas las líneas son suyas.
• Alguien extrajo un módulo a un fichero nuevo → todas las líneas son suyas.

En los tres casos, el contenido no cambió, y blame está señalando al mensajero. Estas tres opciones lo corrigen:

Ignora las diferencias que son solo de espacios en blanco al comparar versiones. Si Bruno pasó el fichero por el formateador y cambió la indentación de 4 a 2 espacios, -w mira a través de ese commit y sigue atribuyendo la línea a quien escribió el código real.

Es prácticamente gratis y casi nunca estorba. Ponlo siempre.

Detecta bloques de líneas que se movieron o copiaron dentro del mismo fichero y atribuye la línea a su origen, no al commit que la movió. Es el caso de "he reordenado las funciones para agrupar las de almacenamiento".

Detecta líneas que vienen de otro fichero modificado en el mismo commit. Es el caso de extraer código a un módulo nuevo.

-C tiene niveles, según cuántas veces se repita, y esta es la tabla que hay que tener a mano:

Y se puede afinar el umbral de detección con un número: -M20 exige al menos 20 caracteres alfanuméricos para considerar que un bloque se movió (por defecto son 40 para -M).

En la práctica, la invocación que resuelve el 95 % de las investigaciones serias es:

Nótese que se puede combinar todo: ignorar espacios, seguir movimientos entre ficheros con nivel medio-alto, y acotado a una función. Es más lento, pero en un fichero de unos cientos de líneas ni se nota.

Comparación práctica del efecto, sobre las mismas líneas:

El primer resultado señala a Bruno y a un commit de julio: es el commit en el que Bruno movió la función de index.html a app.js. Informativamente, es inútil. El segundo señala a los commits que escribieron el contenido, que es lo que buscábamos.

blame acepta un punto de partida distinto de HEAD:

De ahí sale la técnica más útil de todo el apartado: saltar por encima de un commit para ver qué había antes.

Cuando blame te dice que la línea 45 la tocó 3f1a8d6 y ese commit resulta ser un reformateo, quieres saber quién la tocó antes. La respuesta es blamear el padre de ese commit:

3f1a8d6^ es "el padre de 3f1a8d6" (lección 02-06). Al blamear el fichero en ese punto, el commit 3f1a8d6 deja de existir para el análisis y aparece el anterior. Repitiendo el proceso se puede ir retrocediendo capa a capa:

Es tedioso a mano, y por eso existe git log -L (apartado 6), que hace ese recorrido de una vez. Pero conviene conocer la técnica, porque funciona siempre y en cualquier versión de Git.

Otras formas de acotar el rango temporal:

Con --since, las líneas cuyo último cambio es anterior al límite aparecen marcadas con ^ como líneas de frontera: "esto ya estaba antes del periodo que te interesa". Es útil para responder a "¿qué se ha tocado de este fichero este trimestre?" sin ruido de hace tres años.

blame da una foto: el estado actual y quién tocó cada línea por última vez. git log -L da la película: todos los commits que han afectado a un rango de líneas, con su diff.

Misterio resuelto en un solo comando. Los dos replace no son arbitrarios: protegen de los caracteres invisibles que llegan al pegar texto desde el correo. Borrar esa función habría reintroducido un fallo real y difícil de reproducir.

Las formas de -L son las mismas que en blame:

Combinaciones muy útiles:

La comparación entre las dos herramientas, que es la que hay que tener clara:

El flujo natural es encadenarlas: blame para localizar la zona y el commit, log -L para entender la evolución, y git show <sha> para leer el commit completo con su mensaje.

Este apartado resuelve el problema que más envenena el blame en proyectos reales.

El equipo de gestor-tareas decide adoptar Prettier. Ana lo ejecuta sobre todo el proyecto y confirma:

Un solo commit, ningún cambio de comportamiento... y a partir de ahora git blame app.js atribuye a Ana casi todas las líneas del fichero. Toda la información histórica ha quedado sepultada bajo un commit cosmético.

-w ayuda si el cambio fue solo de espaciado, pero Prettier también reordena, parte líneas largas y cambia comillas: -w no basta.

Git analiza el fichero como si ese commit no existiera a efectos de atribución. Las líneas que cambió se atribuyen al commit anterior que las tocó de verdad. Si una línea no se puede reasignar limpiamente, Git la marca con un asterisco * para avisar de que la atribución es aproximada.

Repetir --ignore-rev a mano no escala. La solución es un fichero versionado con la lista de commits a ignorar:

Dos reglas de formato que hay que respetar:

• Hashes completos de 40 caracteres. Los abreviados no valen; Git los rechaza con un error.
• Comentarios con #. Documenta qué era cada commit: dentro de un año nadie lo recordará.

Para conseguir el hash completo:

Ahora se activa en la configuración (lección 01-05):

Y a partir de ese momento, todos los git blame del repositorio lo aplican solos:

La historia real ha vuelto. Y como el fichero está versionado, todo el equipo se beneficia en cuanto ejecute ese git config una vez —el mismo patrón de "fichero versionado + un git config local" que vimos con core.hooksPath en la lección 06-01.

Otras opciones relacionadas:

Cómo hacerlo bien desde el principio: cuando vayas a aplicar un reformateo masivo, hazlo en un commit propio y aislado que no toque nada más, y añádelo al .git-blame-ignore-revs en el commit siguiente. Un reformateo mezclado con cambios funcionales es imposible de ignorar limpiamente y contamina el historial para siempre. Esa disciplina es parte de lo que veremos en la lección 08-02.

Nota práctica: las plataformas de alojamiento (GitHub, GitLab) también leen .git-blame-ignore-revs y lo aplican en su vista de blame, así que el fichero sirve tanto en local como en la web.

Recapitulando la investigación completa de Carla, que es el procedimiento estándar ante cualquier "¿esto para qué está?":

Cuatro comandos, dos minutos, y una respuesta definitiva: la función no se toca, y ahora Carla sabe además que debería llevar un comentario explicativo. Lo añade:

Fíjate en el detalle: el comentario referencia el commit. Es la forma de conectar el código con la explicación completa sin repetirla, y le ahorra a la siguiente persona toda esta investigación.

El nombre del comando es un accidente histórico desafortunado. En inglés, to blame es "culpar", y eso ha creado una asociación desagradable: la idea de que git blame sirve para señalar al responsable de una chapuza.

No es para eso. Git tiene incluso un alias con mejor nombre, heredado de otros sistemas:

Y "anotar" describe mucho mejor lo que hace: enriquecer cada línea con su procedencia.

Los usos legítimos, todos ellos constructivos:

• Entender el porqué. El caso de esta lección. El mensaje del commit contiene el contexto que el código no puede expresar.
• Encontrar a quién preguntar. No para reprochar, sino porque quien escribió algo hace tres meses tiene contexto que tú no tienes.
• Datar un cambio. "¿Esta línea es anterior o posterior a la migración?"
• Evaluar el riesgo de tocar algo. Código de hace tres años que nadie ha tocado y del que nadie se acuerda: proceder con cuidado.
• Documentar hacia atrás. Como acaba de hacer Carla.

Y esto lleva a la conclusión de fondo de la lección, que conviene enunciar sin rodeos:

git blame vale exactamente lo que valen tus mensajes de commit.

Si el commit que aparece dice "Eliminar caracteres invisibles al normalizar el texto de las tareas" con tres líneas explicando el porqué, blame te ha resuelto el problema. Si dice "fix", "cambios" o "asdf", blame te ha dicho quién y cuándo, pero no por qué, que era lo único que necesitabas.

Esa es la conexión directa con la lección 08-01: Escribiendo Buenos Mensajes de Confirmación. Ahí veremos cómo se escribe un mensaje que explique la intención y no la mecánica. Y el argumento definitivo para hacerlo bien es este: no escribes el mensaje para hoy, lo escribes para el git blame que alguien hará dentro de dos años —y ese alguien probablemente serás tú.

Del mismo modo, los commits atómicos (lección 08-02) hacen que el blame señale a un cambio comprensible en lugar de a un commit de 900 líneas titulado "trabajo del viernes".

Error 1: creer que blame dice quién escribió la línea. Dice quién la tocó por última vez. Sin -w, -M, -C e --ignore-rev, la respuesta suele ser "el último que pasó el formateador".

Error 2: blamear el fichero entero. Cientos de líneas de salida para investigar cinco. Usa siempre -L, y sobre todo -L :funcion:fichero.

Error 3: parar en el primer commit que aparece. Si es un movimiento o un reformateo, sigue tirando del hilo con git blame <sha>^ -- <fichero> o pasa directamente a git log -L.

Error 4: buscar con blame una línea que ya no existe. blame solo ve el estado actual. Para código borrado, git log -L, git log -S "texto" (pickaxe) o git log -p -- <fichero>.

Error 5: hashes abreviados en .git-blame-ignore-revs. Git exige los 40 caracteres y falla con un error poco claro si no los pones. Obténlos con git rev-parse.

Error 6: mezclar reformateo y cambios funcionales en un commit. Ese commit ya no se puede ignorar limpiamente y contamina el blame del fichero para siempre. El reformateo, siempre en su propio commit.

Error 7: usar blame para repartir responsabilidades. Además de ser tóxico, es técnicamente poco fiable: la atribución depende de las opciones que uses.

Consejo 1: crea un alias. Lo verás en la lección 06-04, pero adelántalo ya:

Consejo 2: encadena las tres herramientas. blame para localizar, log -L para la evolución, show para el commit completo. Es el procedimiento estándar y no falla.

Consejo 3: cuando resuelvas un misterio, documéntalo en el código. Un comentario con la referencia al commit ahorra la investigación a los siguientes.

Consejo 4: blame en el editor. Prácticamente todos los editores modernos tienen integración (GitLens en VS Code, :Git blame en Vim con fugitive, la anotación integrada de IntelliJ). Enseñan el commit de la línea del cursor sin salir del fichero. Configúralos con -w si te dejan.

Consejo 5: combínalo con bisect. Cuando bisect (lección 06-02) te da el commit culpable, blame sobre las líneas que cambió te dice qué había antes y por qué estaba así.

Crea un repositorio con un fichero app.js que evolucione en cinco commits de tres autores distintos (puedes cambiar de autor con git commit --author="Nombre <correo>"). Después:

1. Ejecuta git blame app.js y comprueba que cada línea se atribuye al commit correcto.
2. Acota con -L a un rango de tres líneas.
3. Usa -L :nombreFuncion:app.js para acotar a una función.
4. Prueba -s, -e y --date=short y compara las salidas.

Sobre el repositorio anterior:

1. Haz un commit que reindente todo el fichero (de 2 a 4 espacios) sin cambiar nada más.
2. Ejecuta git blame y comprueba que ahora todas las líneas son de ese commit.
3. Comprueba que -w recupera la atribución original.
4. Haz otro commit que cambie las comillas dobles por simples en todo el fichero, y comprueba que -w ya no basta.
5. Crea un .git-blame-ignore-revs con ese commit, configura blame.ignoreRevsFile y comprueba que la atribución vuelve.

Sobre el mismo repositorio:

1. Usa git log -L :nombreFuncion:app.js y describe la evolución de la función.
2. Añade una línea a la función, confírmala, y bórrala en otro commit.
3. Comprueba que git blame no muestra rastro de esa línea, pero git log -L sí.
4. Localiza esa misma línea borrada usando el pickaxe git log -S de la lección 02-06.

Solución 1:

Fíjate en un detalle instructivo: la línea 2 se atribuye a Bruno aunque el return texto conceptualmente lo escribió Carla. Es porque Bruno modificó esa línea al partir la expresión en varias. blame opera sobre líneas, no sobre intenciones.

Solución 2:

El cambio no es de espaciado, así que -w no lo atraviesa.

La atribución real ha vuelto, y ahora es automática para todo el repositorio.

Solución 3:

Cuatro commits: dos cosméticos y dos de contenido real. La película completa, incluido lo que blame con --ignore-revs oculta deliberadamente.

-S cuenta apariciones de la cadena y muestra los commits donde ese número cambia: el que la introdujo y el que la quitó. Es la herramienta para lo que ya no está.

git blame convierte el historial en una anotación línea a línea del código que tienes delante. Lo esencial:

• Responde a "¿qué commit tocó esta línea por última vez?", sobre el estado actual del fichero. No dice quién la escribió originalmente, y no ve las líneas borradas.
• La salida tiene cinco columnas —hash, autor, fecha, número de línea y contenido—; ^ marca el commit frontera y 00000000 los cambios sin confirmar.
• -L acota, y -L :funcion:fichero es la forma más cómoda de hacerlo sin contar líneas.
• -w, -M y -C son lo que separa una atribución útil de una inútil: ignoran espaciado y siguen el código movido o copiado, dentro y entre ficheros, con niveles crecientes (-C, -C -C, -C -C -C).
• git blame <sha>^ -- <fichero> salta por encima de un commit para ver qué había antes: la técnica manual para tirar del hilo.
• git log -L da la película completa donde blame da la foto: todos los commits que afectaron a un rango, con sus diffs, incluidas las líneas borradas.
• --ignore-rev y .git-blame-ignore-revs (con blame.ignoreRevsFile) neutralizan los reformateos masivos y devuelven la historia real. Para que funcione, el reformateo tiene que estar en su propio commit aislado.
• El procedimiento estándar ante cualquier "¿esto para qué está?": blame → log -L → show, y grep/log -S para ver quién más depende de ello.
• Y lo más importante: es atribución, no culpa, y vale lo que valgan tus mensajes de commit (lección 08-01).

Carla y el equipo tienen ya un arsenal de consulta considerable: log con sus filtros y su pickaxe, bisect, blame, log -L, show. El problema es que las invocaciones útiles son cada vez más largas —git blame -w -C --date=short -L :funcion:app.js app.js no se escribe a mano dos veces— y que hay vistas del historial que todavía no sabemos pedir: el grafo completo de ramas, solo las fusiones, quién ha contribuido cuánto, o un formato de una línea con colores que se lea de un vistazo.

Toca subir de nivel con git log y, sobre todo, dejar de escribir todo esto a mano. Es la lección 06-04: Git Log y Alias.