La Carla ja ha arreglat l'esborrat de tasques gràcies al bisect. Però mentre era a app.js s'ha trobat amb això:

Ningú de l'equip recorda haver escrit aquesta funció. No està documentada, no té comentaris i té l'aspecte d'un pedaç defensiu contra alguna cosa molt concreta. La temptació d'esborrar-la és enorme: són cinc línies que "no fan res".

Aquesta temptació és exactament l'escenari que descriu la tanca de Chesterton: no treguis una tanca del mig del camp fins que sàpigues per què la van posar. I en un repositori Git sempre es pot saber, perquè cada línia de cada fitxer prové d'un commit concret, amb el seu autor, la seva data i el seu missatge.

L'eina que fa aquesta consulta és git blame, i en aquesta lliçó l'esprémerem: no només per veure qui va tocar la línia per última vegada, sinó per travessar el soroll —reformatatges, codi mogut, canvis d'espaiat— i arribar al commit que de debò explica el perquè.

1. Què és exactament git blame
2. Llegir la sortida
3. Acotar: -L per línies i per funció
4. Veure més enllà del soroll: -w, -M i -C
5. Viatjar en el temps: <sha>^ i --since
6. git log -L: l'evolució completa d'un rang de línies
7. Ignorar commits de format: --ignore-rev i .git-blame-ignore-revs
8. Resolent el misteri de normalitzaText
9. Blame a la pràctica: atribució, no culpa

git blame <fitxer> respon a una pregunta molt concreta:

Per a cada línia del fitxer tal com està ara, quin va ser l'últim commit que la va modificar?

Convé subratllar tres coses d'aquesta definició, perquè els tres malentesos més habituals en surten:

• És "l'últim que la va tocar", no "el que la va escriure". Si l'Ana va escriure la línia al gener i el Bruno li va canviar una coma al juny, blame assenyala el Bruno. Els apartats 4 i 7 són precisament les eines per travessar aquest soroll.
• Treballa sobre l'estat actual del fitxer. Les línies esborrades no hi apareixen: si t'interessen, l'eina és git log -L (apartat 6) o la cerca «pickaxe» -S de la lliçó 02-06.
• No calcula res de nou. Tota la informació ja és al model de dades de la lliçó 01-04: blame recorre l'historial del fitxer comparant versions i atribueix cada línia. És una consulta, no una metadada desada.

Les cinc columnes, d'esquerra a dreta:

I dues marques especials que cal saber llegir:

• ^7d2a1f8, amb accent circumflex: la línia ve del commit més antic del rang analitzat. Sol ser el commit inicial (boundary commit). Vol dir "això és tan vell com el mateix historial que estic mirant".
• 00000000 / "No Confirmat" (Not Committed Yet en anglès): la línia està modificada a l'arbre de treball i encara no s'ha confirmat. És teva, ara mateix.

Opcions de format que estalvien molt de temps:

I la que de debò es fa servir cada dia, perquè combina el just:

Un detall pràctic: la sortida de blame és llarga i sol passar pel paginador. Per saltar directament a la zona que t'interessa, a less n'hi ha prou amb /normalitzaText + Enter. Però és molt millor acotar d'entrada, que és el que ve ara.

Gairebé mai vols el fitxer sencer. -L limita l'anàlisi a un rang:

Maneres d'expressar el rang, totes vàlides:

La forma -L :<nom>:<fitxer> és la més còmoda i la menys coneguda. Git localitza el bloc de la funció fent servir les mateixes regles de funcname que empra git diff per a les capçaleres dels fragments (lliçó 02-05):

Primera pista del misteri: la funció la va crear la Carla al febrer, i l'Ana hi va afegir els dos replace al maig. Dos commits, dos motius possiblement diferents.

El reconeixement de funcions depèn del llenguatge. Git porta patrons integrats per a molts (c, java, python, php, rust...). Per a JavaScript, el patró integrat javascript s'activa declarant-lo al .gitattributes amb *.js diff=javascript. Aquest fitxer, i tot el que permet configurar, és el tema de la lliçó 08-04; aquí n'hi ha prou de saber que si -L :funcio: no encerta, aquesta és la raó.

Aquí hi ha el veritable valor de blame, i el que separa l'ús ingenu de l'ús expert. L'atribució "en brut" menteix constantment, perquè:

• Algú va reindentar el fitxer → totes les línies són seves.
• Algú va moure una funció de lloc dins del mateix fitxer → totes les línies són seves.
• Algú va extreure un mòdul a un fitxer nou → totes les línies són seves.

En els tres casos, el contingut no va canviar, i blame està assenyalant el missatger. Aquestes tres opcions ho corregeixen:

Ignora les diferències que són només d'espais en blanc en comparar versions. Si el Bruno va passar el fitxer pel formatador i va canviar la indentació de 4 a 2 espais, -w mira a través d'aquell commit i continua atribuint la línia a qui va escriure el codi real.

És pràcticament gratis i gairebé mai molesta. Posa-la sempre.

Detecta blocs de línies que es van moure o copiar dins del mateix fitxer i atribueix la línia al seu origen, no al commit que la va moure. És el cas de "he reordenat les funcions per agrupar les d'emmagatzematge".

Detecta línies que vénen d'un altre fitxer modificat al mateix commit. És el cas d'extreure codi a un mòdul nou.

-C té nivells, segons quantes vegades es repeteixi, i aquesta és la taula que cal tenir a mà:

I es pot afinar el llindar de detecció amb un número: -M20 exigeix almenys 20 caràcters alfanumèrics per considerar que un bloc s'ha mogut (per defecte en són 40 per a -M).

A la pràctica, la invocació que resol el 95 % de les investigacions serioses és:

Fixa't que es pot combinar tot: ignorar espais, seguir moviments entre fitxers amb nivell mitjà-alt, i acotat a una funció. És més lent, però en un fitxer d'uns centenars de línies ni es nota.

Comparació pràctica de l'efecte, sobre les mateixes línies:

El primer resultat assenyala el Bruno i un commit de juliol: és el commit en què el Bruno va moure la funció d'index.html a app.js. Informativament, és inútil. El segon assenyala els commits que van escriure el contingut, que és el que buscàvem.

blame accepta un punt de partida diferent d'HEAD:

D'aquí surt la tècnica més útil de tot l'apartat: saltar per damunt d'un commit per veure què hi havia abans.

Quan blame et diu que la línia 45 la va tocar 3f1a8d6 i aquell commit resulta ser un reformatatge, vols saber qui la va tocar abans. La resposta és fer blame del pare d'aquell commit:

3f1a8d6^ és "el pare de 3f1a8d6" (lliçó 02-06). En fer blame del fitxer en aquell punt, el commit 3f1a8d6 deixa d'existir per a l'anàlisi i apareix l'anterior. Repetint el procés es pot anar retrocedint capa a capa:

És tediós a mà, i per això existeix git log -L (apartat 6), que fa aquest recorregut d'una sola vegada. Però convé conèixer la tècnica, perquè funciona sempre i en qualsevol versió de Git.

Altres maneres d'acotar el rang temporal:

Amb --since, les línies l'últim canvi de les quals és anterior al límit apareixen marcades amb ^ com a línies de frontera: "això ja hi era abans del període que t'interessa". És útil per respondre a "què s'ha tocat d'aquest fitxer aquest trimestre?" sense soroll de fa tres anys.

blame dona una foto: l'estat actual i qui va tocar cada línia per última vegada. git log -L dona la pel·lícula: tots els commits que han afectat un rang de línies, amb el seu diff.

Misteri resolt en una sola ordre. Els dos replace no són arbitraris: protegeixen dels caràcters invisibles que arriben en enganxar text des del correu. Esborrar aquesta funció hauria reintroduït una fallada real i difícil de reproduir.

Les formes de -L són les mateixes que a blame:

Combinacions molt útils:

La comparació entre les dues eines, que és la que cal tenir clara:

El flux natural és encadenar-les: blame per localitzar la zona i el commit, log -L per entendre l'evolució, i git show <sha> per llegir el commit complet amb el seu missatge.

Aquest apartat resol el problema que més enverina el blame en projectes reals.

L'equip de gestor-tasques decideix adoptar Prettier. L'Ana l'executa sobre tot el projecte i confirma:

Un sol commit, cap canvi de comportament... i a partir d'ara git blame app.js atribueix a l'Ana gairebé totes les línies del fitxer. Tota la informació històrica ha quedat sepultada sota un commit cosmètic.

-w ajuda si el canvi va ser només d'espaiat, però Prettier també reordena, parteix línies llargues i canvia cometes: -w no n'hi ha prou.

Git analitza el fitxer com si aquell commit no existís a efectes d'atribució. Les línies que va canviar s'atribueixen al commit anterior que les va tocar de debò. Si una línia no es pot reassignar netament, Git la marca amb un asterisc * per avisar que l'atribució és aproximada.

Repetir --ignore-rev a mà no escala. La solució és un fitxer versionat amb la llista de commits a ignorar:

Dues regles de format que cal respectar:

• Hashos complets de 40 caràcters. Els abreujats no valen; Git els rebutja amb un error.
• Comentaris amb #. Documenta què era cada commit: d'aquí a un any ningú ho recordarà.

Per aconseguir el hash complet:

Ara s'activa a la configuració (lliçó 01-05):

I a partir d'aquell moment, tots els git blame del repositori l'apliquen sols:

La història real ha tornat. I com que el fitxer està versionat, tot l'equip se'n beneficia tan bon punt executi aquell git config una vegada —el mateix patró de "fitxer versionat + un git config local" que vam veure amb core.hooksPath a la lliçó 06-01.

Altres opcions relacionades:

Com fer-ho bé des del principi: quan vagis a aplicar un reformatatge massiu, fes-lo en un commit propi i aïllat que no toqui res més, i afegeix-lo al .git-blame-ignore-revs al commit següent. Un reformatatge barrejat amb canvis funcionals és impossible d'ignorar netament i contamina l'historial per sempre. Aquesta disciplina és part del que veurem a la lliçó 08-02.

Nota pràctica: les plataformes d'allotjament (GitHub, GitLab) també llegeixen .git-blame-ignore-revs i l'apliquen a la seva vista de blame, així que el fitxer serveix tant en local com al web.

Recapitulant la investigació completa de la Carla, que és el procediment estàndard davant de qualsevol "això per a què hi és?":

Quatre ordres, dos minuts, i una resposta definitiva: la funció no es toca, i ara la Carla sap a més que hauria de portar un comentari explicatiu. L'hi afegeix:

Fixa't en el detall: el comentari referencia el commit. És la manera de connectar el codi amb l'explicació completa sense repetir-la, i estalvia a la persona següent tota aquesta investigació.

El nom de l'ordre és un accident històric desafortunat. En anglès, to blame és "culpar", i això ha creat una associació desagradable: la idea que git blame serveix per assenyalar el responsable d'una nyap.

No és per a això. Git té fins i tot un àlies amb millor nom, heretat d'altres sistemes:

I "anotar" descriu molt millor el que fa: enriquir cada línia amb la seva procedència.

Els usos legítims, tots ells constructius:

• Entendre el perquè. El cas d'aquesta lliçó. El missatge del commit conté el context que el codi no pot expressar.
• Trobar a qui preguntar. No per retreure res, sinó perquè qui va escriure alguna cosa fa tres mesos té context que tu no tens.
• Datar un canvi. "Aquesta línia és anterior o posterior a la migració?"
• Avaluar el risc de tocar alguna cosa. Codi de fa tres anys que ningú ha tocat i del qual ningú es recorda: cal procedir amb cura.
• Documentar cap enrere. Com acaba de fer la Carla.

I això porta a la conclusió de fons de la lliçó, que convé enunciar sense embuts:

git blame val exactament el que valen els teus missatges de commit.

Si el commit que apareix diu "Elimina els caràcters invisibles en normalitzar el text de les tasques" amb tres línies explicant el perquè, blame t'ha resolt el problema. Si diu "fix", "canvis" o "asdf", blame t'ha dit qui i quan, però no per què, que era l'única cosa que necessitaves.

Aquesta és la connexió directa amb la lliçó 08-01: Escrivint Bons Missatges de Confirmació. Allà veurem com s'escriu un missatge que expliqui la intenció i no la mecànica. I l'argument definitiu per fer-ho bé és aquest: no escrius el missatge per a avui, l'escrius per al git blame que algú farà d'aquí a dos anys —i aquest algú probablement seràs tu.

De la mateixa manera, els commits atòmics (lliçó 08-02) fan que el blame assenyali un canvi comprensible en lloc d'un commit de 900 línies titulat "feina del divendres".

Error 1: creure que blame diu qui va escriure la línia. Diu qui la va tocar per última vegada. Sense -w, -M, -C i --ignore-rev, la resposta sol ser "l'últim que va passar el formatador".

Error 2: fer blame del fitxer sencer. Centenars de línies de sortida per investigar-ne cinc. Fes servir sempre -L, i sobretot -L :funcio:fitxer.

Error 3: aturar-se al primer commit que apareix. Si és un moviment o un reformatatge, continua estirant del fil amb git blame <sha>^ -- <fitxer> o passa directament a git log -L.

Error 4: buscar amb blame una línia que ja no existeix. blame només veu l'estat actual. Per a codi esborrat, git log -L, git log -S "text" (pickaxe) o git log -p -- <fitxer>.

Error 5: hashos abreujats a .git-blame-ignore-revs. Git exigeix els 40 caràcters i falla amb un error poc clar si no els poses. Obtén-los amb git rev-parse.

Error 6: barrejar reformatatge i canvis funcionals en un commit. Aquell commit ja no es pot ignorar netament i contamina el blame del fitxer per sempre. El reformatatge, sempre en el seu propi commit.

Error 7: fer servir blame per repartir responsabilitats. A més de ser tòxic, és tècnicament poc fiable: l'atribució depèn de les opcions que facis servir.

Consell 1: crea un àlies. El veuràs a la lliçó 06-04, però avança'l ja:

Consell 2: encadena les tres eines. blame per localitzar, log -L per a l'evolució, show per al commit complet. És el procediment estàndard i no falla.

Consell 3: quan resolguis un misteri, documenta'l al codi. Un comentari amb la referència al commit estalvia la investigació als següents.

Consell 4: blame a l'editor. Pràcticament tots els editors moderns tenen integració (GitLens al VS Code, :Git blame al Vim amb fugitive, l'anotació integrada d'IntelliJ). Ensenyen el commit de la línia del cursor sense sortir del fitxer. Configura'ls amb -w si et deixen.

Consell 5: combina'l amb bisect. Quan bisect (lliçó 06-02) et dona el commit culpable, blame sobre les línies que va canviar et diu què hi havia abans i per què estava així.

Crea un repositori amb un fitxer app.js que evolucioni en cinc commits de tres autors diferents (pots canviar d'autor amb git commit --author="Nom <correu>"). Després:

1. Executa git blame app.js i comprova que cada línia s'atribueix al commit correcte.
2. Acota amb -L a un rang de tres línies.
3. Fes servir -L :nomFuncio:app.js per acotar a una funció.
4. Prova -s, -e i --date=short i compara les sortides.

Sobre el repositori anterior:

1. Fes un commit que reindenti tot el fitxer (de 2 a 4 espais) sense canviar res més.
2. Executa git blame i comprova que ara totes les línies són d'aquell commit.
3. Comprova que -w recupera l'atribució original.
4. Fes un altre commit que canviï les cometes dobles per simples a tot el fitxer, i comprova que -w ja no n'hi ha prou.
5. Crea un .git-blame-ignore-revs amb aquell commit, configura blame.ignoreRevsFile i comprova que l'atribució torna.

Sobre el mateix repositori:

1. Fes servir git log -L :nomFuncio:app.js i descriu l'evolució de la funció.
2. Afegeix una línia a la funció, confirma-la, i esborra-la en un altre commit.
3. Comprova que git blame no mostra rastre d'aquella línia, però git log -L sí.
4. Localitza aquella mateixa línia esborrada fent servir la cerca «pickaxe» git log -S de la lliçó 02-06.

Solució 1:

Fixa't en un detall instructiu: la línia 2 s'atribueix al Bruno encara que el return text conceptualment el va escriure la Carla. És perquè el Bruno va modificar aquella línia en partir l'expressió en diverses. blame opera sobre línies, no sobre intencions.

Solució 2:

El canvi no és d'espaiat, així que -w no el travessa.

L'atribució real ha tornat, i ara és automàtica per a tot el repositori.

Solució 3:

Quatre commits: dos de cosmètics i dos de contingut real. La pel·lícula completa, inclòs el que blame amb --ignore-revs amaga deliberadament.

-S compta aparicions de la cadena i mostra els commits on aquest número canvia: el que la va introduir i el que la va treure. És l'eina per al que ja no hi és.

git blame converteix l'historial en una anotació línia a línia del codi que tens al davant. L'essencial:

• Respon a "quin commit va tocar aquesta línia per última vegada?", sobre l'estat actual del fitxer. No diu qui la va escriure originalment, i no veu les línies esborrades.
• La sortida té cinc columnes —hash, autor, data, número de línia i contingut—; ^ marca el commit frontera i 00000000 els canvis sense confirmar.
• -L acota, i -L :funcio:fitxer és la manera més còmoda de fer-ho sense comptar línies.
• -w, -M i -C són el que separa una atribució útil d'una d'inútil: ignoren l'espaiat i segueixen el codi mogut o copiat, dins i entre fitxers, amb nivells creixents (-C, -C -C, -C -C -C).
• git blame <sha>^ -- <fitxer> salta per damunt d'un commit per veure què hi havia abans: la tècnica manual per estirar del fil.
• git log -L dona la pel·lícula completa on blame dona la foto: tots els commits que van afectar un rang, amb els seus diffs, incloses les línies esborrades.
• --ignore-rev i .git-blame-ignore-revs (amb blame.ignoreRevsFile) neutralitzen els reformatatges massius i tornen la història real. Perquè funcioni, el reformatatge ha d'estar en el seu propi commit aïllat.
• El procediment estàndard davant de qualsevol "això per a què hi és?": blame → log -L → show, i grep/log -S per veure qui més en depèn.
• I el més important: és atribució, no culpa, i val el que valguin els teus missatges de commit (lliçó 08-01).

La Carla i l'equip ja tenen un arsenal de consulta considerable: log amb els seus filtres i la seva cerca «pickaxe», bisect, blame, log -L, show. El problema és que les invocacions útils són cada cop més llargues —git blame -w -C --date=short -L :funcio:app.js app.js no s'escriu a mà dues vegades— i que hi ha vistes de l'historial que encara no sabem demanar: el graf complet de branques, només les fusions, qui ha contribuït quant, o un format d'una línia amb colors que es llegeixi d'un cop d'ull.

Toca pujar de nivell amb git log i, sobretot, deixar d'escriure tot això a mà. És la lliçó 06-04: Git Log i Àlies.