Fins ara sempre hem mirat endavant: crear el repositori, preparar canvis, confirmar-los, revisar el diff abans de registrar-lo. Aquesta lliçó canvia el sentit de la mirada. Anem a consultar el passat.

I aquí hi ha el veritable valor de Git. Desar versions no serveix de gaire si després no pots respondre preguntes com ara: quan es va introduir aquesta funció? Qui va tocar estils.css la setmana passada i per què? En quina confirmació va desaparèixer aquella línia que juraries haver escrit? Què es va fer al projecte entre dilluns i dijous?

git log les respon totes, però la seva sortida per defecte és només la punta de l'iceberg. És una ordre enormement configurable: formats compactes, gràfics, resums per fitxer, plantilles pròpies i una bateria de filtres que permeten localitzar una confirmació entre milers. En aquesta lliçó la recorrerem sencera, juntament amb git show per inspeccionar una confirmació concreta i les diferents formes de referir-se a un commit, que hem anat fent servir de passada (HEAD, HEAD~1) sense explicar-les del tot.

1. El repositori d'en Bruno: el nostre banc de proves
2. git log per defecte
3. Formats compactes: --oneline i --graph
4. Veure què va canviar: --stat i --patch
5. Formats personalitzats amb --pretty=format:
6. Filtrar l'historial: quantitat, dates, autor i missatge
7. Filtrar per ruta i la cerca «pickaxe» (-S i -G)
8. git show: inspeccionar una confirmació
9. Com referir-se a una confirmació
10. Combinacions útils per al dia a dia

Han passat uns dies des que en Bruno va clonar el projecte. L'Ana ja tenia quatre confirmacions quan ell hi va arribar, i des de llavors en Bruno n'ha fet tres més a la seva pròpia còpia. Aquest és l'historial que té al seu MacBook:

Set confirmacions: les quatre de l'Ana que van arribar amb el clon i les tres que ha fet en Bruno en local. Fixa't en (origin/main): marca el punt on era el servidor quan en Bruno va clonar. Les seves tres confirmacions són per davant d'aquella marca perquè encara no les ha enviat; això és matèria del mòdul 4.

Aquest historial mixt ens anirà molt bé: té dos autors, dates diferents i canvis sobre fitxers diferents, que és justament el que necessitem per practicar els filtres.

(La sortida continua; se surt del paginador amb q.)

Cada entrada té quatre elements:

Un parell de precisions importants:

• L'ordre és cronològic invers: el més recent a dalt. És el que vols el 95 % de les vegades. S'inverteix amb --reverse.
• Author i Committer són camps diferents. Recorda del model de dades que un commit desa tots dos. Normalment coincideixen i git log només mostra el primer; se separen quan algú aplica un pedaç aliè o en fer rebase. Per veure'ls tots dos:

• git log només mostra l'historial assolible des d'on ets. Per defecte parteix de HEAD i va seguint els enllaços als pares. Confirmacions que existeixin en altres branques no hi apareixen llevat que les demanis explícitament o facis servir --all.

Una línia per confirmació: hash abreujat, referències que hi apunten i primera línia del missatge. És el format que més es fa servir, i explica per què aquella primera línia ha de funcionar tota sola: en aquesta vista és l'únic que es veu.

--oneline és en realitat una drecera de --pretty=oneline --abbrev-commit.

Dibuixa el graf de confirmacions amb caràcters de text:

Amb una sola línia de desenvolupament, el gràfic és una columna d'asteriscs i no aporta gaire. El seu valor apareix quan hi ha branques i fusions, on mostra les bifurcacions i els punts d'unió:

Aquest és l'aspecte que tindrà l'historial de l'equip a partir del mòdul 3. Per veure el graf de totes les branques, no només l'actual:

--decorate mostra les referències (branques, etiquetes, HEAD) al costat de cada confirmació. A Git modern està activat per defecte al terminal, però convé conèixer-lo.

És la vista més útil per fer-se una idea ràpida de la mida i l'abast de cada canvi sense llegir el codi. Variants:

Mostra l'historial amb el diff de cada confirmació, en el format unified diff que vas aprendre a llegir a la lliçó anterior. És la manera més completa de revisar feina, i també la més llarga: fes-la servir sempre amb un límit (-1, -5) o combinada amb un filtre.

Una combinació especialment valuosa:

Mostra l'evolució completa d'un sol fitxer, confirmació a confirmació, amb el diff de cadascuna. És com veure una pel·lícula del fitxer des del seu naixement.

Quan cap dels formats predefinits no encaixa, pots dissenyar el teu amb una plantilla:

Els marcadors comencen per %. Aquests són els que de debò es fan servir:

Els marcadors %C... controlen el color i fan la sortida molt més llegible:

Colors disponibles: red, green, yellow, blue, magenta, cyan, white, i %C(auto) perquè Git decideixi. %C(reset) torna al color normal, i %C(bold …) dona negreta.

Aquesta plantilla és un clàssic i mereix desar-se com a àlies:

Els àlies es desen al ~/.gitconfig amb el mecanisme que vam veure a Configurant Git, i es tracten a fons a Git Log i Àlies.

En un projecte de dos anys, git log retorna milers d'entrades. Els filtres són el que converteix l'ordre en una eina de cerca.

Git accepta expressions en llenguatge natural (en anglès), cosa que és molt còmoda:

El valor és una expressió regular que es busca tant al nom com al correu, així que n'hi ha prou amb un fragment:

I el filtre simètric per al confirmador:

També és una expressió regular, i per defecte distingeix majúscules. Per ignorar-les:

Diversos --grep es combinen amb O lògic per defecte; --all-match els converteix en I:

I compte amb això: quan combines filtres de tipus diferent, s'apliquen amb I lògic:

Confirmacions d'en Bruno, del 30 de juliol endavant, el missatge de les quals contingui «estil». Una de sola.

Només les confirmacions que van modificar aquell fitxer. Igual que a git diff, el -- separa opcions de rutes i és obligatori quan el nom es podria confondre amb una branca.

Accepta directoris i patrons:

Combinat amb -p, és la millor manera d'entendre com va arribar un fitxer a ser el que és:

--follow segueix el fitxer a través de reanomenaments. Sense aquesta opció, l'historial es tallaria en el moment en què el fitxer va canviar de nom. Només funciona amb un fitxer alhora.

Aquí arriba una de les capacitats més útils i menys conegudes de Git. -S busca les confirmacions en què va canviar el nombre d'aparicions d'una cadena. A la pràctica: quan es va introduir o es va eliminar aquell text.

Una sola confirmació: aquella en què va aparèixer la funció. Si més endavant algú l'esborrés, aquella confirmació també hi sortiria.

Compara-ho amb --grep, que és una cosa completament diferent:

El cas d'ús estrella de -S és aquest: trobes al codi una línia estranya, vols saber per què hi és, i git blame només et diu qui la va tocar per última vegada. Amb -S trobes la confirmació original que la va introduir, amb el seu missatge explicatiu.

Mostra la confirmació on va aparèixer aquella declaració CSS, amb el seu diff. Cerca quirúrgica.

Per veure-ho amb més detall:

La diferència amb -S és subtil però important:

• -S "text" troba els commits on va canviar el nombre de vegades que apareix aquell text. Si mous una línia de lloc dins del mateix fitxer, el nombre no canvia i -S no la troba.
• -G "regex" troba tots els commits el diff dels quals conté alguna línia afegida o eliminada que casi amb l'expressió. Un moviment sí que hi apareix.

Regla pràctica: -S per a «quan es va introduir això?»; -G per a «quins commits van tocar alguna cosa semblant a això?».

Totes dues accepten --pickaxe-regex i es combinen amb la resta de filtres:

Quan ja has localitzat la confirmació que t'interessa, git show te l'ensenya sencera:

Metadades i diff en una sola vista. És equivalent a git log -p -1 <commit>, però més directe.

git show és més versàtil del que sembla, perquè accepta qualsevol objecte de Git:

La sintaxi <commit>:<ruta> és especialment útil. Ja la vam fer servir al mòdul anterior per comprovar quina versió d'un fitxer havia quedat registrada. Serveix, per exemple, per recuperar una versió antiga sense tocar res més:

I combinada amb -s i un format, git show serveix per extreure dades concretes:

Portem estona fent servir HEAD, HEAD~1 i hashos sense haver sistematitzat la notació. Tanquem-la, perquè apareix pràcticament a totes les ordres de Git.

N'hi ha prou d'escriure un prefix inequívoc. Git necessita almenys 4 caràcters i en fa servir 7 per defecte en mostrar-los. En repositoris molt grans pot caldre'n algun més; si el prefix és ambigu, Git t'avisa:

Aquests dos són els que confonen, i la diferència només importa quan hi ha fusions (commits amb més d'un pare):

En resum:

• ~ recorre generacions cap enrere per la línia principal. ~3 = tres passos enrere.
• ^ tria entre els pares d'un mateix commit. ^2 = el segon pare.

En un historial lineal com el d'en Bruno, HEAD~2 i HEAD^^ són exactament el mateix:

El diagrama ho aclareix:

Les fletxes apunten cap enrere perquè així és com funciona Git: cada commit coneix el seu pare, no els seus fills. Per això és fàcil recórrer l'historial cap al passat i no existeix una notació senzilla per anar cap al futur.

I quan hi hagi fusions (mòdul 3), ^ prendrà sentit:

Dos punts defineixen un rang de confirmacions:

Es llegeix com «les confirmacions assolibles des de c5d9b1e però no des de 8b6d3c2». És a dir: el que hi ha després de 8b6d3c2 fins a c5d9b1e inclòs. Fixa't que l'extrem esquerre queda fora.

Formes molt utilitzades:

Aquest penúltim és exactament el que en Bruno té pendent d'enviar:

Les seves tres confirmacions locals. Tot això es desenvoluparà al mòdul 4.

git rev-parse tradueix qualsevol notació a un hash complet, i és la manera de sortir de dubtes:

Un receptari de consultes que resolen preguntes reals:

I una advertència pràctica: git log obre un paginador. Es recorre amb les fletxes o la barra espaiadora, s'hi busca amb /text i se'n surt amb q. Si prefereixes la sortida directa:

• Confondre --grep amb -S. --grep busca al missatge de la confirmació; -S busca al contingut dels fitxers. Són preguntes completament diferents i és l'error més freqüent en buscar a l'historial.
• Oblidar el -- abans d'una ruta. git log estils.css funciona si no hi ha ambigüitat, però git log main interpretarà main com una branca. Posa-hi -- sempre que puguis dubtar.
• Esperar que git log mostri totes les branques. Per defecte només recorre l'historial assolible des de HEAD. Per veure-ho tot, --all.
• Interpretar malament els rangs a..b. L'extrem esquerre no s'hi inclou. git log HEAD~3..HEAD retorna tres confirmacions, no quatre.
• Fer servir ~ quan es vol ^. En un historial lineal són intercanviables, però en una fusió HEAD^2 (el segon pare) i HEAD~2 (dues generacions enrere) apunten a llocs diferents.
• Quedar-se atrapat al paginador. Se'n surt amb q. És una de les primeres frustracions de tothom amb Git.
• Buscar dins de git log -p a ull. Si busques on va aparèixer un text concret, -S t'ho dona en una ordre en lloc de fer-te llegir cent diffs.
• No fer servir --follow en mirar l'historial d'un fitxer reanomenat. Veuràs un historial que «comença» al reanomenament i conclouràs erròniament que el fitxer és recent.
• Consell: defineix l'àlies lg de l'apartat 5. El faràs servir a diari i fa l'historial molt més llegible.
• Consell: git shortlog -sn és la manera més ràpida de saber qui treballa en un projecte que acabes de clonar. I git log --oneline -20 et dona el pols del que s'està fent ara mateix.
• Consell: si vols exportar l'historial per a un informe, --pretty=format: combinat amb --date=short produeix línies fàcils de processar amb qualsevol full de càlcul.

Partint de l'historial d'en Bruno tal com apareix a l'apartat 1:

Escriu l'ordre exacta per a cada consulta i prediu-ne la sortida:

1. Les tres últimes confirmacions, en una línia cadascuna.
2. Totes les confirmacions de l'Ana.
3. Tot el que s'ha fet entre el 23 i el 27 de juliol, tots dos inclosos.
4. Les confirmacions que van tocar estils.css.
5. Les confirmacions el missatge de les quals contingui «tasca», sense distingir majúscules.
6. Un llistat amb format hash | data curta | autor | assumpte.
7. Quantes confirmacions hi ha en total i quantes n'ha fet cada persona.
8. El contingut de README.md tal com era a 4e7f2a9.

Crea un repositori amb un historial en què una línia apareix, es mou i desapareix:

1. Què retorna git log --oneline -S "DEPURACIO"? Explica per què apareix cada confirmació i per què en falta alguna.
2. Què retorna git log --oneline -G "DEPURACIO"? Compara-ho amb el resultat anterior i explica la diferència.
3. Què retorna git log --oneline --grep="DEPURACIO"? I --grep="depuració"?
4. Escriu l'ordre que mostri el diff de la confirmació exacta en què es va eliminar la traça.
5. Redacta en una frase la regla que et permetrà triar entre -S, -G i --grep en el futur.

Sobre el repositori de l'exercici 2 (quatre confirmacions, historial lineal):

1. Escriu quatre formes diferents de referir-te a la segona confirmació de l'historial (la que va afegir la traça).
2. Comprova amb git rev-parse que HEAD~2 i HEAD^^ apunten al mateix objecte.
3. Mostra el contingut d'app.js tal com era a la primera confirmació, sense modificar el teu directori de treball.
4. Mostra únicament els missatges de les dues últimes confirmacions, sense diff.
5. Fes servir un rang per llistar només les dues últimes confirmacions i explica per què HEAD~2..HEAD en retorna dues i no tres.
6. Esbrina quins fitxers va modificar cadascuna de les quatre confirmacions amb una sola ordre.

Solució a l'Exercici 1

1. Les tres últimes:

2. Les de l'Ana:

3. Entre el 23 i el 27, tots dos inclosos:

Atenció al detall: --until="2026-07-27" s'interpreta com les 00:00 d'aquell dia, així que exclouria les confirmacions del mateix dia 27. Com que aquí volem incloure el dia 27 sencer, hi posem --until="2026-07-28". És un error clàssic que fa «desaparèixer» confirmacions de l'últim dia del rang.

4. Les que van tocar estils.css:

Nota: 1a4c8d6 va crear el fitxer, així que en un historial real també hi apareixeria. A l'enunciat s'indica que la confirmació inicial contenia els quatre fitxers, de manera que la sortida completa seria de tres entrades.

5. Missatges amb «tasca», sense distingir majúscules:

Cinc de les set. En queden fora c5d9b1e («Documenta la instal·lació al README») i 8b6d3c2 («Afegeix els estils base del llistat»), els missatges de les quals no contenen la paraula.

6. Format personalitzat:

7. Totals:

8. El README a 4e7f2a9:

Mostra el contingut del fitxer tal com era en aquella confirmació, sense tocar el directori de treball. Si el volguéssim desar a part:

Solució a l'Exercici 2

1. Amb -S:

Dues confirmacions. -S busca canvis en el nombre d'aparicions de la cadena:

• 9b3e5d7: va passar de 0 aparicions a 1. Va canviar → hi apareix.
• 1f4c8a2: va passar d'1 a 0. Va canviar → hi apareix.

Hi falta 7a2d6f9 («Mou la traça a la funció fi i afegeix-la»). I aquí hi ha el matís que cal entendre: en aquella confirmació la traça es va moure d'inici() a fi(), així que continua apareixent una sola vegada. Com que el recompte no varia (1 → 1), -S la considera irrellevant i no la mostra.

2. Amb -G:

Tres confirmacions. -G no compta aparicions: mira si el diff de la confirmació conté alguna línia afegida o eliminada que casi amb l'expressió. A 7a2d6f9 hi ha una línia amb DEPURACIO eliminada i una altra d'afegida, així que sí que hi apareix.

Aquesta és exactament la diferència entre totes dues opcions, i l'exercici l'aïlla en la seva forma més pura.

3. Amb --grep:

Cap, perquè --grep busca al missatge, i cap missatge no conté la paraula en majúscules.

Dues: les que porten aquella paraula al missatge. Que coincideixin amb el resultat de -S és pura casualitat de l'exemple; es deu al fet que els missatges descriuen bé el que fan.

4. El diff de l'eliminació:

O, més directe i més llegible, localitzar el commit i mostrar-lo:

Una manera robusta d'encadenar-ho, sense conèixer el hash per endavant:

que mostra la confirmació més recent en què va canviar el recompte d'aquella cadena: precisament l'eliminació.

5. La regla:

--grep busca al missatge («qui va dir que feia això?»); -S busca quan va aparèixer o desaparèixer un text al codi («d'on va sortir aquesta línia?»); -G busca quines confirmacions van tocar línies que casen amb un patró, moviments inclosos («qui ha rondat per aquí?»).

Solució a l'Exercici 3

1. Quatre formes de referir-se a la segona confirmació (amb HEAD a la quarta):

I n'hi ha més: el hash complet, main~2, @~2… Totes resolen al mateix objecte.

2. Comprovació:

Hashos idèntics. En un historial lineal ~n i n símbols ^ són equivalents, perquè cada commit té un únic pare i «triar el primer pare» i «retrocedir una generació» són la mateixa operació. La diferència només emergeix a les fusions.

3. El fitxer a la primera confirmació:

git show <commit>:<ruta> llegeix de l'historial i escriu a la sortida estàndard. No modifica res, a diferència de git restore --source=..., que sí que sobreescriuria el fitxer del disc.

4. Només els missatges de les dues últimes:

O, si prefereixes la vista completa sense el diff:

5. El rang:

Dues confirmacions, no tres, perquè l'extrem esquerre del rang queda exclòs. a..b significa «tot el que és assolible des de b que no ho sigui des d'a», i HEAD~2 és assolible des d'ell mateix, així que es descarta. La manera de llegir-ho és: «el que ha passat després de HEAD~2».

Si també volguessis incloure HEAD~2, hauries d'escriure HEAD~3..HEAD.

6. Fitxers modificats per cada confirmació:

Les tres últimes confirmacions modifiquen app.js (M) i la primera l'afegeix (A), cosa que és coherent: era el root-commit i el fitxer no existia abans.

Amb aquesta lliçó tanquem el cicle bàsic de Git i el mòdul 2. Recapitulant el que hem après aquí:

• git log recorre l'historial cap enrere des de HEAD, en ordre cronològic invers, seguint els enllaços als pares.
• Els formats canvien completament el que veus: --oneline per a la vista de treball, --graph per a l'estructura (imprescindible tan bon punt hi hagi branques), --stat per a l'abast de cada canvi i -p per al diff complet.
• --pretty=format: permet dissenyar la teva pròpia sortida amb marcadors com %h, %an, %ar i %s, i val la pena desar-la com a àlies.
• Els filtres converteixen git log en un cercador: -n per quantitat, --since/--until per data, --author per persona, --grep per missatge i -- <ruta> per fitxer. Filtres de tipus diferent es combinen amb I lògic.
• La cerca «pickaxe» és la joia amagada: -S troba quan va aparèixer o desaparèixer un text al codi, i -G quines confirmacions van tocar línies que casen amb un patró. No confonguis cap de les dues amb --grep, que mira el missatge.
• git show inspecciona una confirmació concreta —metadades i diff— i amb la sintaxi <commit>:<ruta> recupera qualsevol fitxer tal com era en qualsevol moment del passat.
• Referir-se a una confirmació es pot fer per hash (complet o abreujat), per referència simbòlica (HEAD, main, origin/main, una etiqueta) o per navegació relativa: ~ retrocedeix generacions i ^ tria entre pares. Els rangs a..b exclouen l'extrem esquerre.

Has recorregut el cicle complet de treball amb Git en solitari:

1. Crear el repositori (git init) o unir-te a un d'existent (git clone).
2. Treballar seguint el cicle editar → preparar → confirmar, amb git status com a brúixola.
3. Triar amb precisió què entra a cada confirmació, fins i tot a nivell de fragment amb git add -p.
4. Revisar els canvis amb git diff abans de registrar-los.
5. Consultar el passat amb git log i git show.

Amb això ja pots fer servir Git de manera productiva en qualsevol projecte propi. Però hi ha un problema esperant.

Fixa't en la situació real en què són l'Ana i en Bruno ara mateix. Tots dos han estat treballant sobre main, cadascú al seu portàtil, sense coordinar-se. L'Ana ha afegit el comptador de tasques i el marcatge de completades; en Bruno ha afegit el filtre de pendents i ha tocat els mateixos fitxers. Cap dels dos no ha vist la feina de l'altre.

Quan intentin ajuntar tot això, es trobaran amb dues versions diferents d'app.js que han evolucionat per separat des del mateix punt de partida. I això és només amb dues persones i una setmana de feina: quan la Carla s'incorpori des de Windows i hi hagi tres línies de desenvolupament simultànies, treballar tots sobre main serà insostenible.

A més, hi ha un problema més subtil. Ara mateix, si l'Ana vol provar una idea arriscada, no té on fer-ho: qualsevol cosa que confirmi va directa a l'única línia del projecte. I si a mitja tasca urgent apareix una fallada crítica, ha d'abandonar el que està fent o confirmar-ho a mitges.

La resposta a tot això són les branques, i són la característica que va convertir Git en l'estàndard de la indústria. Al mòdul 3: Branques i Fusió veurem què és realment una branca (spoiler: ja ho saps, és un fitxer amb un hash a dins, com vam comprovar en crear el primer commit), com crear-les i moure's entre elles, com fusionar la feina de diverses persones, quines estratègies fa servir Git per fer-ho, com resoldre els conflictes quan dues persones toquen la mateixa línia, i com mantenir endreçat un repositori amb moltes branques vives.

Tot el que has après en aquest mòdul —les tres zones, l'àrea de preparació, el diff, l'historial— continua sent vàlid exactament igual. Només que a partir d'ara hi haurà més d'una línia de treball alhora.