Portem sis mòduls ajornant aquesta lliçó. A la 03-02 vam dir que el reflog explica com Git recorda per on ha passat HEAD. A la 03-06 vam prometre que esborrar una branca amb -D gairebé mai no és irreversible, i vam remetre aquí. A la 05-01 vam dir que un rebase desastrós es pot desfer, i vam remetre aquí. A la 05-04, que un stash drop accidental és recuperable. A la 09-02, que els commits que un reset --hard deixa enrere continuen allà. I a la 09-03, que origin/main@{1} guarda on era el servidor abans de la reescriptura.

Totes aquestes promeses s'aguanten sobre la mateixa peça, i és hora de desenvolupar-la sencera.

El reflog és probablement la funcionalitat de Git amb millor relació entre el que salva i el poc que es coneix. Molta gent porta anys fent servir Git sense haver-lo executat mai, i és exactament l'ordre que converteix «he perdut tres dies de feina» en «he trigat dos minuts a recuperar-ho».

Comencem pel més important: si has arribat aquí en pànic, no has perdut res, sempre que allò que busques arribés a ser un commit. Continua llegint amb calma.

1. Què és el reflog i on viu
2. Local i temporal: els dos límits que cal conèixer
3. Llegir git reflog
4. HEAD@{n} davant de HEAD@{temps}
5. El patró universal de recuperació
6. Receptari: reset --hard, branca esborrada, rebase, merge, --amend
7. Quan el reflog no n'hi ha prou: git fsck --lost-found
8. Recuperar un desament temporal eliminat
9. Els límits reals: el que no es pot recuperar
10. Higiene: no destruir la teva pròpia xarxa de seguretat

El reflog és el registre local de tots els moviments de cada referència.

Cada vegada que una referència —HEAD, una branca, una branca de seguiment remota— canvia de valor, Git escriu una línia en un fitxer de text anotant d'on venia, on va, qui ho ha fet i per què.

Mira-t'ho directament:

Cada línia té: hash anterior, hash nou, identitat, marca de temps, i descripció de l'operació. És text pla, sense màgia.

L'estructura de directoris:

I aquí hi ha la clau de tot el mòdul. Recupera la idea de la lliçó 09-01:

Un commit sobreviu mentre alguna cosa hi arribi. Les entrades del reflog compten com a referències.

Per això git gc no elimina un commit que apareix al reflog, encara que cap branca no l'apunti. El reflog no és només un registre: és el que manté vius els objectes orfes. Aquesta és la raó tècnica que la recuperació funcioni.

Abans del receptari, les dues limitacions. No entendre-les és el que fa que algú confiï en el reflog quan no ha de fer-ho.

El reflog no viatja. No es publica amb push, no es baixa amb fetch, i un git clone no el porta.

Una sola entrada. Tot l'historial de moviments que l'Ana tenia a la seva màquina es queda a la seva màquina.

Tres conseqüències pràctiques:

1. El reflog de l'Ana no pot rescatar el desastre del Bruno. Cadascú té el seu.
2. El reflog no és una còpia de seguretat. Si el disc mor, mor amb ell. Les còpies de seguretat reals són git bundle i els mateixos clons de l'equip (lliçó 09-05).
3. Un clon acabat de fer no té xarxa de seguretat. El primer reset --hard desafortunat en un clon nou sí que et pot deixar sense res a recuperar, perquè no hi ha entrades anteriors.

I una conseqüència positiva, la de l'apartat 9 de la lliçó 09-03: si un company força i destrueix una branca del servidor, el teu reflog d'origin/branca conserva on era, i amb ell es restaura.

Les entrades caduquen. Dos paràmetres ho governen:

La segona és la que importa: els commits realment orfes tenen 30 dies. Després, un git gc els purga definitivament.

La caducitat no passa sola: l'executa git gc (lliçó 08-06), que Git llança automàticament quan s'acumulen objectes solts. A la pràctica, tens setmanes, no mesos, i encara menys anys.

Pots allargar el termini:

Costa uns quants megabytes i compra molta tranquil·litat.

I el contrari, que mai no has d'executar tret que sàpigues exactament què fas (lliçó 08-06):

Com es llegeix:

• HEAD@{0} és sempre l'última cosa que ha passat. L'ordre va del present cap al passat.
• El hash de cada línia és on va quedar HEAD DESPRÉS d'aquella operació. Aquest detall és crucial i produeix l'error més freqüent: si vols l'estat anterior a l'operació de HEAD@{0}, necessites el hash de HEAD@{1}.
• La descripció diu quina ordre ho ha provocat.

El vocabulari de les descripcions:

Molt més net que el de HEAD quan saps quina branca t'interessa, perquè no inclou els canvis de branca.

--date=relative és el que més ajuda en una recuperació: «ho tenia just abans de dinar» es tradueix directament a una entrada.

I git log -g (o --walk-reflogs), que recorre el reflog mostrant cada entrada com un commit complet:

Útil quan no reconeixes un commit pel seu missatge i necessites veure quins fitxers tocava.

Dues sintaxis que s'assemblen i signifiquen coses diferents.

La distinció crítica, i mereix un exemple:

HEAD~3 recorre el graf: segueix la cadena de pares. HEAD@{3} recorre la teva història personal: pot ser en una altra branca, en un commit orfe, en qualsevol lloc on hagis estat.

Quan has fet un reset, HEAD~1 et porta al pare del commit actual (que ja no és el que buscaves) i HEAD@{1} et porta on eres abans del reset (que sí que ho és).

Les formes temporals accepten expressions molt naturals:

I l'avís que dona Git quan et passes de termini:

No és un error: t'està dient que ha fet servir l'entrada més antiga disponible. Si la data que has demanat és anterior, el resultat no és el que et penses.

Totes les receptes de l'apartat següent són el mateix procediment. Aprèn-te'l una vegada.

El pas 4 és el que cal interioritzar, i és la diferència entre una recuperació tranquil·la i un segon ensurt:

git branch és purament additiu. Si el hash era l'equivocat, esborres la branca i en proves un altre. No s'ha mogut res. Amb reset --hard cada intent fallit afegeix una capa més de confusió.

I el pas 3, verificar, evita l'error de recuperar el commit equivocat:

I per inspeccionar sense comprometre't a res:

La situació. L'Ana volia treure un commit i va escriure HEAD~3.

No has perdut res (tret del que estigués sense confirmar, lliçó 09-02).

HEAD@{1} (9c4e7b2) és la punta que hi havia just abans del reset.

Recuperat. Ara, si vols que GT-241 torni a ser això:

La drecera, si acabes de fer-ho i no has fet res més (lliçó 09-02):

O directament amb la sintaxi del reflog:

Això tanca la promesa de la lliçó 03-06.

Primer regal: Git imprimeix el hash en esborrar. Si el tens al buffer del terminal, la recuperació és immediata:

Si has tancat el terminal, hi ha dos camins.

A. El reflog de HEAD (funciona si vas estar en aquella branca):

B. Buscar per missatge entre tots els commits orfes (funciona sempre):

O directament sobre la base d'objectes:

I el detall important que s'oblida: el reflog de la branca mateixa s'esborra amb ella.

.git/logs/refs/heads/GT-247 ja no existeix. Per això cal buscar al reflog de HEAD, que sí que sobreviu.

-D gairebé mai no és irreversible. Els commits continuen a .git/objects, assolibles des del reflog de HEAD, durant almenys 30 dies. La promesa de la lliçó 03-06 queda complerta.

I l'excepció, per ser honestos: si la branca es va crear, se li van fer commits i es va esborrar sense que HEAD hi passés mai (per exemple, amb git branch X <hash> i després git branch -D X), el reflog de HEAD no la registra. En aquest cas, git fsck de l'apartat 7.

Això tanca la promesa de la lliçó 05-01.

El Bruno ha fet un rebase -i de deu commits, ha aixafat els que no havia d'aixafar i ha acabat amb --continue.

L'entrada clau és rebase (start): l'anterior a ella és l'estat exacte previ al rebase. Aquí, HEAD@{5} → 9c4e7b2.

Els deu commits originals, intactes.

Una drecera que gairebé ningú no coneix: durant un rebase, Git desa la posició inicial a ORIG_HEAD, i també en una referència especial:

I si el rebase encara no ha acabat, la sortida és molt més simple:

Torna tot exactament a l'estat previ. Fes-lo servir sempre que puguis: és més net que recuperar després.

Per comparar el resultat amb l'original i decidir què fer, git range-diff (lliçó 07-02):

Si acabes de fer-lo i no hi ha res a sobre:

merge sempre escriu ORIG_HEAD abans de fusionar. És la sortida canònica.

Si ja has fet més coses a sobre:

HEAD@{2} és l'estat previ a la fusió. Però compte: si hi tornes, perds també el commit c7e2a91 que has fet després. El correcte és rescatar-lo a part:

I si el merge ja està publicat, res de reflog: la resposta és git revert -m 1 (lliçó 05-06).

Un cas freqüent i desconcertant: git merge --abort no funciona perquè la fusió va acabar bé; només era mala idea. --abort serveix mentre hi ha conflictes sense resoldre, no després.

La Carla ha fet git commit --amend i s'ha adonat que ha perdut part del missatge original —o pitjor, que el commit anterior tenia canvis que el nou no té.

No has perdut res. --amend no modifica el commit: en crea un de nou i mou la branca (lliçó 09-01). L'original continua a la base de dades.

HEAD@{1} (8f4c2a9) és el commit original, abans de l'--amend.

I les maneres de recuperar, segons el que necessitis:

Reprenent l'apartat 5.7 de la lliçó 09-01: has fet commits en HEAD desacoblat i te n'has anat.

La línia checkout: moving from 9c4e7b2 to main et dona el hash d'on vas sortir.

El reflog registra els moviments de referències. Hi ha objectes que arriben a la base de dades sense que cap referència es mogui, i per a aquests cal l'altra eina.

I a més crea un directori amb enllaços:

dangling és normal i inofensiu. No és un símptoma de corrupció. És el que s'espera en qualsevol repositori actiu. La distinció entre això i els errors de debò (missing, broken link) és la lliçó 09-05.

Un fsck pot tornar desenes de línies. La feina és identificar quin és el teu.

Això converteix una llista de hashos en informació utilitzable. Desa-ho com a àlies:

Inspecció individual, amb les eines de lampisteria de la lliçó 01-04:

Aquest és el cas que salva més feina del que la gent espera. Si vas preparar un fitxer amb git add i després el vas perdre, el contingut és a la base de dades (lliçó 09-01, taula de l'apartat 1).

Buscar per una cadena que recordis és molt més eficaç que revisar els blobs un a un.

Això tanca la promesa de la lliçó 05-04.

Primer regal, un altre cop: drop imprimeix el hash. Amb ell:

I si va ser un git stash clear, que esborra tota la pila sense imprimir res, hi ha dos camins.

A. El reflog del desament temporal, si encara existeix:

stash clear esborra la referència, però el fitxer de log a vegades sobreviu fins al següent gc. Val la pena mirar-lo primer.

B. Buscar els commits del desament temporal entre els inassolibles:

Els desaments temporals es reconeixen pel seu missatge: WIP on <branca>: (els automàtics) o On <branca>: <missatge> (els que has creat amb -m).

Un desament temporal és internament un commit de fusió amb dos o tres pares, i val la pena veure-ho perquè explica com funciona:

I la recuperació:

Toca ser honestos. Hi ha dues fronteres que cap tècnica d'aquesta lliçó no travessa.

Ja ho vam veure a la lliçó 09-01, i és la limitació fonamental:

Quan ets en un dels tres últims casos, Git ja no et pot ajudar. El que queda és fora de Git:

1. L'historial local del teu editor. És la via que més vegades funciona i la que menys es prova.

• VS Code: paleta d'ordres → «Local History: Find Entry to Restore». Desa versions de cada fitxer que has editat, independentment de Git.
• IntelliJ / WebStorm / Eclipse: menú contextual del fitxer → Local History → Show History. Desa setmanes.
• Vim: si tens set undofile, l'historial de desfer persisteix entre sessions (:earlier 1h).

2. Còpies de seguretat del sistema: Time Machine a macOS, instantànies de Btrfs/ZFS, versions anteriors a Windows, còpies al núvol.

3. Buscar a /tmp i als fitxers d'intercanvi de l'editor (.swp de Vim, ~ d'altres).

Si es va executar git gc --prune=now després que el commit quedés orfe, l'objecte ha desaparegut físicament. Si a més es va executar git reflog expire --expire=now --all, no en queda ni registre.

Comprova si encara hi és abans de rendir-te:

Aquest missatge significa que l'objecte ja no existeix. Però abans de donar-lo per perdut, mira fora de la teva màquina:

Aquesta és la xarxa de seguretat del model distribuït, i és el tema central de la lliçó 09-05.

La cinquena és la més infravalorada. Una branca publicada és a dues màquines. Cap accident local no hi pot fer res.

Tanca la lliçó el que no s'ha de fer.

1. git reflog expire --expire=now --all. Buida el registre. Tot el que és orfe queda desprotegit.

2. git gc --prune=now. Elimina immediatament els objectes inassolibles. Té el seu ús legítim (després d'un filter-repo de la lliçó 08-05, on esborrar és justament l'objectiu), i cap en un dia normal.

3. Confiar en el reflog com a còpia de seguretat. És local, temporal i mor amb el disc. No és una còpia de seguretat.

4. Recuperar amb reset --hard en lloc de git branch. Cada intent fallit afegeix confusió. branch no mou res.

5. Treballar mesos sense publicar una branca. Un clon nou té el reflog buit; una branca sense publicar existeix en un sol disc.

I una comprovació de salut de trenta segons, per saber si la teva xarxa de seguretat és on et penses:

Error 1: no provar git reflog. És la primera ordre davant de qualsevol «he perdut commits», i la majoria de la gent no l'executa mai.

Error 2: confondre HEAD@{1} amb HEAD~1. El primer és on eres fa una operació; el segon és el commit pare. Després d'un reset, són coses completament diferents.

Error 3: agafar el hash de l'entrada equivocada. El hash d'una línia és on va quedar HEAD després d'aquella operació. Per a l'estat previ a HEAD@{0}, necessites HEAD@{1}.

Error 4: recuperar amb reset --hard en lloc de git branch. Si el hash era l'equivocat, amb branch esborres la branca i en proves una altra; amb reset cada intent complica més l'estat.

Error 5: creure que el reflog viatja en un clone. No viatja. El clon nou té una sola entrada i cap xarxa de seguretat.

Error 6: confiar en el reflog per sempre. 90 dies per al que és assolible, 30 per al que és orfe, i gc els aplica. A la pràctica, setmanes.

Error 7: espantar-se amb els dangling de git fsck. Són normals en qualsevol repositori actiu. El greu és missing i broken link (lliçó 09-05).

Error 8: donar per perdut un desament temporal. stash drop imprimeix el hash, stash clear deixa els commits orfes, i tots dos es recuperen amb git fsck --unreachable buscant WIP on.

Error 9: rendir-se sense mirar fora de Git. L'historial local de l'editor recupera el que Git no pot, i gairebé ningú no ho prova.

Consell 1: el patró és sempre el mateix. Reflog → verificar amb git show → git branch rescat <hash>.

Consell 2: git reflog --date=relative. «Ho tenia abans de dinar» es tradueix directament a una entrada.

Consell 3: defineix l'àlies git perduts. El dia que el necessitis no recordaràs la canonada de fsck i awk.

Consell 4: git rebase --abort mentre puguis. Molt més net que recuperar després.

Consell 5: allarga el reflog a un any. Dues línies de configuració global i uns quants megabytes.

Consell 6: publica les teves branques. Una branca en dues màquines és immune als accidents d'una.

Sobre un repositori de proves amb app.js, estils.css i index.html:

1. Crea sis commits a main i una branca GT-241 amb tres commits propis.
2. Provoca quatre desastres seguits, sense recuperar entre l'un i l'altre: a. git reset --hard HEAD~2 a GT-241. b. git switch main && git branch -D GT-241. c. Un git commit --amend a main que esborri part del missatge. d. Un git merge d'una branca experimental que no volies.
3. Executa git reflog --date=relative i anota, per a cada desastre, quina entrada faries servir.
4. Recupera les quatre coses fent servir sempre git branch, mai reset.
5. Verifica cada recuperació amb git show --stat i git diff.

1. En un repositori nou, crea tres situacions: un commit, un fitxer preparat amb git add, i un fitxer modificat només al disc.
2. Executa git reset --hard HEAD~1.
3. Recupera el commit amb el reflog i el fitxer preparat amb git fsck --lost-found + git cat-file -p.
4. Documenta per què el tercer és irrecuperable, comprovant-ho amb git fsck i git reflog.
5. Crea un desament temporal amb -u, elimina'l amb git stash clear i recupera'l amb git fsck --unreachable.
6. Comprova amb git show --format='%p' -s que el desament té tres pares i inspecciona'n cadascun.

1. Crea un repositori amb deu commits i provoca cinc commits orfes amb reset.
2. Comprova que apareixen a git fsck --lost-found.
3. Executa git reflog expire --expire=now --all i torna a mirar git reflog i git fsck. Explica la diferència entre les dues sortides.
4. Executa git gc --prune=now i comprova amb git cat-file -t <hash> que els objectes han desaparegut de debò.
5. Repeteix l'experiment configurant abans gc.reflogExpireUnreachable "1 year" i explica què canvia.
6. Escriu la comprovació de salut de l'apartat 10 en un guió i interpreta'n la sortida en un repositori real teu.

Solució 1:

Fixa't en el matís de (b): després del reset --hard, GT-241 apuntava a 6e2b9c7, i això és el que va esborrar -D (8a1f6c3 a l'exemple del missatge). Però el que l'Ana vol és l'estat previ al reset, 9c4e7b2. El reflog els conserva tots dos.

Cap d'aquestes operacions no ha mogut main. Tot el que hi havia continua on era, i ara a més hi ha tres punts d'accés al que s'ha recuperat.

Els tres commits, inclosos els dos que el reset --hard havia deixat enrere.

El missatge original, abans que l'--amend el deixés en chore.

L'única cosa que va aportar el merge no desitjat. Per desfer-lo:

I per restaurar GT-241 de debò:

Solució 2:

Un sol objecte penjant (el de l'add), cap entrada de reflog, i ni un byte a tot .git. La línia NOMES AL DISC mai no es va convertir en objecte: no se'n va calcular el SHA, no es va comprimir, no es va escriure. Git no pot tornar el que mai no va rebre. Les úniques vies serien l'historial local de l'editor o una còpia del sistema de fitxers.

Recuperat íntegre, inclòs el fitxer sense seguiment.

Tres pares exactament com deia l'apartat 8: HEAD, l'índex i els fitxers sense seguiment. Un desament temporal és un commit, i per això sobreviu a stash clear.

Solució 3:

La diferència clau: el reflog és buit, però els objectes continuen allà. reflog expire esborra el registre, no els objectes. Encara es poden recuperar amb fsck... però ja no saps quina era la punta ni en quin ordre estaven, perquè aquella informació vivia al reflog. Recuperable, sí; còmode, no.

Ara sí que ha desaparegut de debò. L'objecte ja no existeix a .git/objects. Cap tècnica d'aquesta lliçó no el recupera; només un clon aliè o una còpia de seguretat.

El gc --prune=now no ha pogut purgar res, perquè les entrades del reflog continuen vigents i el reflog compta com a referència. Aquest és el mecanisme exacte que manté vius els objectes orfes, i per això allargar la caducitat protegeix de debò.

L'última línia és la que dona més informació en un repositori real: cada branca sense upstream existeix en un sol disc.

El reflog és la raó per la qual gairebé res no es perd a Git, i saber-ho canvia per complet la relació amb les ordres destructives.

• El reflog registra cada moviment de cada referència, en text pla sota .git/logs/. I no és només un registre: les seves entrades compten com a referències, i per això mantenen vius els commits als quals no arriba cap branca.
• És local: no viatja en un clone, no es publica, i mor amb el disc. No és una còpia de seguretat. I és temporal: 90 dies per al que és assolible, 30 per al que és orfe, que gc aplica.
• HEAD@{n} no és HEAD~n. El primer recorre la teva història personal de moviments; el segon recorre el graf. Després d'un reset, són coses diferents, i confondre'ls és l'error més comú.
• El patró de recuperació és sempre el mateix: git reflog → verificar amb git show --stat → git branch rescat <hash>. Crear una branca és additiu i no mou res; reset --hard complica cada intent fallit.
• El receptari cobreix tot el que aquest curs havia anat prometent: desfer un reset --hard (entrada anterior al reset:), recuperar una branca esborrada amb -D (el hash que imprimeix, o el reflog de HEAD, perquè el de la branca s'esborra amb ella), rescatar un rebase (entrada anterior a rebase (start), o --abort si continua en marxa), desfer un merge (ORIG_HEAD) i recuperar el que se'n va endur un --amend (l'entrada commit: anterior).
• Quan el reflog no n'hi ha prou, git fsck --lost-found: els objectes dangling són normals, i entre ells hi ha els commits orfes i els blobs d'un git add que mai no es va confirmar. git cat-file -p i git show els inspeccionen.
• Un desament temporal és un commit amb dos o tres pares (HEAD, índex, sense seguiment), i per això sobreviu a drop i a clear: es busca per WIP on entre els inassolibles i es torna amb git stash store.
• Els límits són reals: el que mai no va ser objecte (modificacions sense add, fitxers esborrats per clean) i el que ja ha passat per gc --prune. Aquí només salven l'historial local de l'editor, una còpia del sistema o el clon d'un company.
• I la prevenció que fa innecessària tota la lliçó: confirmar sovint, posar un git branch abans del que és arriscat, stash push -u abans de netejar, allargar el reflog a un any i publicar les branques.

Fins aquí, tot s'aguantava sobre una premissa: que la base de dades d'objectes estigués sana. Els objectes existien, els hashos quadraven i Git els podia llegir.

I quan no? Quan git status respon error: object file .git/objects/4f/8a2e6... is empty, quan una referència apunta a un objecte que no existeix, quan l'índex és corrupte i Git es nega a fer absolutament res. Això ja no és un problema de referències mal posades: és un problema d'integritat, i té el seu propi diagnòstic, les seves pròpies reparacions i —el més important— un criteri clar per saber quan cal deixar d'intentar arreglar-ho i tornar a clonar.

Continua a la lliçó 09-05: Tractant amb Repositoris Corruptes.