La lliçó anterior va deixar el catàleg muntat i va resoldre els casos d'un minut. Ara toca l'ordre que apareixia a mitja dotzena de files d'aquella taula i que portem cinc mòduls prometent: git reset.

És probablement l'ordre pitjor entesa de Git. Té tres modes que fan coses diferents, dues formes d'invocar-la que es comporten de manera completament diferent, i una fama de perillosa que és merescuda només en un dels seus usos. La confusió no és casual: reset fa dues feines que en altres sistemes serien dues ordres diferents.

Aquesta lliçó el desmunta peça a peça i després el posa en context. Perquè reset no és la resposta a "vull desfer alguna cosa": és una de les respostes, i triar l'equivocada és el que converteix un canvi no desitjat en un problema per a tot l'equip. Al final tindràs una taula de decisió que respon l'única pregunta que importa: on és allò que vull desfer?

I un advertiment que val per a tota la lliçó: aquí apareix l'única ordre de Git que destrueix de debò, sense cap xarxa de seguretat possible. No és reset. És git clean.

1. Les tres zones, una altra vegada
2. git reset mou la branca: la idea central
3. Els tres modes: --soft, --mixed, --hard
4. Casos ordenats pel que vols desfer
5. git reset <commit> -- <ruta>: l'altra forma
6. git restore: l'ordre moderna per a la feina diària
7. git clean: el que sí que destrueix
8. ORIG_HEAD: la xarxa de seguretat immediata
9. La taula de decisió

Tot reset s'entén tan bon punt es recuperen les tres zones de la lliçó 01-03. Val la pena tenir-les al davant:

Tres fotos del projecte que poden coincidir o no:

Quan git status diu "Changes to be committed", està comparant índex amb HEAD. Quan diu "Changes not staged for commit", compara directori de treball amb índex. Amb això clar, reset deixa de ser un misteri: cada mode decideix fins a quina d'aquestes tres zones arriba el canvi.

Abans dels modes, l'operació bàsica. Això és el que fa git reset <commit> sempre, en els tres modes:

Mou la branca actual perquè apunti a <commit>. I com que HEAD apunta a la branca, HEAD es mou amb ella.

No esborra commits. No modifica commits. Reescriu un fitxer de 41 bytes (lliçó 03-01).

b52c9d1 i 7d3a8f4 continuen existint íntegres a .git/objects. El que ha canviat és que GT-241 ja no hi arriba, així que git log no els mostra. Recuperar-los és trivial mentre el reflog els recordi (lliçó 09-04).

D'aquí surten les dues conseqüències que cal interioritzar:

1. reset és segur sobre feina local. Encara que t'equivoquis, els commits continuen allà.

2. reset és perillós sobre feina publicada. Perquè moure la branca enrere i tornar a avançar produeix una història diferent de la que tenen els altres. El push serà rebutjat (non-fast-forward), i forçar-lo destruiria la feina dels altres. És la regla d'or de la lliçó 05-01, i el seu tractament complet és la lliçó 09-03.

Un tercer matís que gairebé ningú no coneix i que evita molts ensurts:

Sense argument de commit, reset fa servir HEAD, és a dir, no mou res. Només actua sobre l'índex. Per això git reset a seques és completament inofensiu: buida l'àrea de preparació i deixa els teus fitxers intactes.

La diferència entre els tres és fins on propaga el canvi.

Visualment, sobre les tres zones:

El commit ha desaparegut de la branca, i tot el seu contingut és preparat, a punt per tornar-se a confirmar. Els M i A amb la lletra a la primera columna signifiquen "a l'índex".

És el mode de "vull refer aquest commit". De fet, és exactament el que fa git commit --amend per dins.

Ara la lletra és a la segona columna: els canvis són al directori de treball, sense preparar. I estils.css, que era nou, ha tornat a ser un fitxer sense seguiment.

És el mode de "vull refer aquest commit i tornar a triar què hi entra". És el que vas fer servir a la lliçó 05-02 per dividir un commit en dos.

Tot net, com si aquell commit no hagués existit mai. I aquí hi ha el perill, que convé enunciar amb precisió:

--hard no destrueix els commits (continuen a la base de dades). Destrueix els canvis sense confirmar que hi hagués en aquell moment a l'índex i al directori de treball.

Això és el que no té marxa enrere, perquè mai no va ser a .git/objects (lliçó 09-01, taula de l'apartat 1).

Una excepció important i tranquil·litzadora: --hard no toca els fitxers sense seguiment. Si tenies un notes.txt que no vas afegir mai, continua allà. El que s'emporta per davant són les modificacions de fitxers seguits.

La fila del --hard és la que cal memoritzar: s'emporta dues coses alhora, el commit i la teva feina en curs. I només una de les dues es pot recuperar.

Existeixen i en dues situacions són exactament el que vols:

--keep és un --hard educat: mou la branca i actualitza els fitxers que difereixen, però avorta si això trepitjaria un canvi local. És l'opció sensata quan vols retrocedir i no estàs segur de tenir-ho tot confirmat:

Aquest error, aquí, és una bona notícia: t'ha salvat.

--merge és semblant però intenta fusionar els canvis locals a la destinació. Es fa servir sobretot per avortar una fusió a mà.

Regla pràctica: quan tinguis la temptació d'escriure --hard i no n'estiguis segur, escriu --keep. Si funciona, no hi havia res a perdre; si falla, acabes d'evitar el problema.

Aquest és el receptari. Està ordenat de menor a major abast.

L'Ana ha estat provant coses a estils.css i vol tornar a com estava.

Això sí que destrueix, i sense xarxa: les modificacions no confirmades no són enlloc. Git ni tan sols pregunta.

El Bruno ha fet git add . i hi ha ficat sense voler notes-personals.md.

No has perdut res: el fitxer continua modificat al directori de treball, només deixa d'estar preparat.

Fixa't en l'asimetria, que és la font de confusió número u:

git restore sense opcions actua sobre el directori de treball. Amb --staged, sobre l'índex. És el contrari del que molta gent assumeix, i és la raó que git restore mereixi el seu propi apartat (el 6).

El cas més freqüent de tots. La Carla ha confirmat i s'ha adonat que el commit barreja dues coses.

No has perdut res. El commit ja no és a la branca, però tot el seu contingut és preparat. Ara el pot refer:

Si a més vol tornar a triar què entra a cada commit, --mixed i git add -p (lliçó 02-04):

Aquest és el flux complet de "he barrejat dues coses en un commit", i és el que es fa servir a diari.

No cal reset per a això. --amend substitueix l'últim commit (lliçó 02-04), i amb -m ni tan sols obre l'editor:

Recorda que el hash canvia: si estava publicat, això reescriu historial.

Tres commits fora de la branca. Abans d'executar-ho, dos costums que costen cinc segons:

Amb git branch copia-GT-241, el --hard deixa de ser irreversible en cap sentit: els commits continuen sent assolibles des de la còpia. És el mateix patró que a la lliçó 09-01, apartat 5.2, i el que es generalitza a la 09-04.

I si ja ho vas fer sense còpia: tampoc no passa res, mentre no fossin canvis sense confirmar.

És el "descarta tot el meu i deixa'm com el servidor". Útil quan la teva còpia local s'ha embolicat sense remei i saps que no hi ha res teu a salvar.

Comprova abans què llençaràs:

Si la primera llista no és buida, no executis el --hard sense crear abans una branca de còpia.

Aquí reset no és la resposta. Reescriure una branca publicada obliga a forçar el push i destrueix la feina de qui tingui la versió anterior.

La resposta és git revert (lliçó 05-06): crea un commit nou amb el canvi invers, no reescriu res, no cal forçar, i en queda constància.

L'única excepció: una branca publicada que és exclusivament teva (la teva branca de treball GT-241, que ningú més no fa servir). Aquí sí que pots reescriure i forçar amb --force-with-lease, i això és la lliçó 09-03.

Aquí hi ha la font principal de confusió amb reset, i mereix un apartat propi.

Quan hi afegeixes una ruta, git reset fa una cosa completament diferent:

git reset <commit> -- <ruta> NO mou la branca. Copia l'estat de <ruta> a <commit> a l'índex, i deixa el directori de treball intacte.

Per què no pot moure la branca: moure HEAD a un altre commit és una operació sobre el repositori sencer. No existeix "moure la branca només per a un fitxer". Així que quan dones una ruta, Git entén que vols l'altra operació: omplir l'índex des d'un commit.

Conseqüència directa: git reset <commit> -- <ruta> no accepta --hard.

Precisament perquè el mode --hard implica tocar el directori de treball, i aquesta forma no ho fa mai.

És la manera de preparar el contingut antic d'un fitxer, típicament per desfer només una part d'un commit:

L'índex té ara la versió anterior d'estils.css, preparada. Un git commit crea un commit que desfà només aquesta part.

I si a més vols que el fitxer al disc canviï, la forma moderna i molt més clara és git restore:

Reprenent la lliçó 08-03:

git rm --cached treu el fitxer de l'índex (deixa de tenir seguiment) però el conserva al disc. És l'operació que cal fer quan alguna cosa va entrar al repositori i després la vas afegir al .gitignore. És una cosina germana de git reset -- <ruta>, però per deixar de seguir el fitxer en lloc de restaurar-ne el contingut.

Git 2.23 va partir el vell git checkout en dues ordres amb noms honestos: git switch per a les branques (lliçó 03-02) i git restore per als fitxers. És l'eina que hauries de fer servir a diari, deixant reset per al que de debò implica moure la branca.

La taula d'equivalències amb el que és antic, perquè veuràs les dues formes a la documentació i a les respostes de fòrum:

git restore -p mereix una menció a part. És el germà de git add -p: t'ensenya cada fragment del diff i et pregunta si el vols descartar. És la manera quirúrgica de desfer part d'un canvi sense perdre la resta, i evita el "descartaré tot i ho refaré".

Perfecte per treure els console.log de depuració conservant la feina real.

Tot l'anterior té xarxa de seguretat en algun grau. Aquesta ordre no en té cap, i per això mereix el to més seriós de la lliçó.

git clean esborra fitxers sense seguiment. I un fitxer sense seguiment no ha passat mai per .git/objects: no hi ha commit, no hi ha blob, no hi ha reflog, no hi ha fsck que valgui. Quan git clean l'esborra, està esborrat, igual que amb rm.

-n (o --dry-run) no esborra res: només llista. Llegeix-ho sencer. Si en aquesta llista apareix alguna cosa que t'importa, no executis l'ordre real.

Aquest costum no és opcional. És la diferència entre netejar el projecte i perdre el fitxer de configuració local que portes sis mesos mantenint a mà.

Els usos habituals:

-x és la que cal mirar dues vegades. Esborra el que el .gitignore protegeix, i allà sol haver-hi precisament el que no és al repositori però sí que t'importa: .env amb la configuració local, credencials de desenvolupament, bases de dades de prova.

L'opció 4 (ask each) pregunta un per un. Quan hi ha molts fitxers i només en sobren alguns, és la manera correcta.

La combinació que circula per internet com a "deixar-ho tot net":

Això deixa el directori exactament com un clon acabat de fer d'aquell commit. I s'emporta per davant, sense preguntar i sense recuperació possible:

• Tots els canvis sense confirmar de fitxers seguits.
• Tots els fitxers nous que no havies afegit.
• Tot el que està ignorat: .env, node_modules/, configuracions locals, bases de dades de prova.

És una ordre legítima —en CI, en un contenidor, en un repositori d'usar i llençar— i una catàstrofe a la màquina d'algú que portava dues hores treballant. No l'enganxis mai sense haver executat abans git clean -ndx i llegit la llista.

git stash -u (lliçó 05-04) desa també els fitxers sense seguiment, i els desa com a objectes de Git. Amb això, el que anaves a esborrar passa a ser a la base de dades i, per tant, deixa de ser irrecuperable. Costa un segon.

Abans d'una operació que mou HEAD de manera substancial —reset, merge, rebase, pull—, Git desa la posició anterior en una referència especial:

Així que el "desfer" immediat d'un reset és:

O, seguint el patró segur:

Dos advertiments sobre ORIG_HEAD:

• Només desa una posició, la de l'última operació. Si fas dos reset seguits, la primera es perd. Per a això hi ha el reflog, que desa tot l'historial de moviments (lliçó 09-04).
• No recupera canvis sense confirmar. ORIG_HEAD és un hash de commit: torna la branca al seu lloc, no la teva feina en curs.

És la xarxa de seguretat dels trenta segons següents. Per a tota la resta, la 09-04.

La pregunta correcta no és "quina ordre faig servir per desfer?", sinó "on és allò que vull desfer?". Amb aquesta resposta, l'ordre és immediata.

I en forma de taula, que és com es consulta en el moment:

La fila que governa totes les altres és la de "està publicat?". Si la resposta és sí i la branca és compartida, reset surt de la llista i l'única eina correcta és revert.

Error 1: creure que reset --hard esborra commits. No els esborra: mou la branca. Els commits continuen a .git/objects i el reflog els troba (09-04). El que sí que destrueix són els canvis sense confirmar.

Error 2: fer servir --hard quan n'hi havia prou amb --soft. Si només volies refer el commit, --soft ho conserva tot preparat. --hard s'emporta a més la teva feina en curs.

Error 3: confondre git restore <f> amb git restore --staged <f>. El primer destrueix el canvi al disc; el segon només el treu de l'índex i no perd res. Són gairebé oposats.

Error 4: esperar que git reset <commit> -- <ruta> mogui la branca. No ho fa mai, i per això --hard amb rutes dona error. És una altra operació amb el mateix nom.

Error 5: executar git clean -fdx copiat d'internet. Esborra .env, configuracions locals i tot el que està ignorat, sense recuperació possible. -n primer, sempre.

Error 6: fer reset en una branca compartida i forçar el push. Destrueix la feina de qui tingués els commits. En el que està publicat, revert (05-06).

Error 7: fer servir git reset --hard origin/main sense comprovar què hi ha de teu al davant. git log --oneline origin/main..HEAD costa un segon i et diu exactament què llençaràs.

Error 8: oblidar que --hard respecta els fitxers sense seguiment. No és un error greu, però explica el "he fet reset --hard i això continua aquí": no tenia seguiment.

Consell 1: quan dubtis entre --hard i no fer res, fes servir --keep. Fa el mateix, però avorta en lloc de trepitjar canvis locals.

Consell 2: git branch copia-<alguna-cosa> abans de qualsevol reset --hard. Costa dos segons i converteix l'operació en trivialment reversible.

Consell 3: fes servir git restore i git switch en lloc de git checkout. Els noms diuen el que fan i eviten errors per confusió.

Consell 4: git restore -p per treure els console.log. Quirúrgic, i conserva la resta de la feina.

Consell 5: git stash push -u abans de qualsevol neteja. Converteix l'irrecuperable en recuperable per un segon d'esforç.

Consell 6: recorda ORIG_HEAD. El desfer immediat d'un reset, merge, rebase o pull que acabes de lamentar.

1. Crea un repositori amb app.js i tres commits. Al tercer, afegeix-hi també estils.css.
2. Modifica app.js sense confirmar i crea un fitxer nou notes.txt sense afegir-lo.
3. Executa git reset --soft HEAD~1 i anota la sortida de git status --short i git log --oneline -1.
4. Desfés-ho amb git reset --hard ORIG_HEAD... i observa què ha passat amb la teva modificació d'app.js. Explica-ho.
5. Repeteix l'experiment complet amb --mixed i amb --hard, i omple una taula amb tres columnes: log -1, canvi sense confirmar a app.js, i notes.txt.
6. Explica per què notes.txt sobreviu fins i tot a --hard.

1. Sobre un repositori amb quatre commits, on el tercer va modificar app.js, estils.css i index.html, prova git reset --hard HEAD~1 -- app.js i explica l'error.
2. Fes servir git reset HEAD~2 -- estils.css i comprova amb git status, git diff i git diff --cached en quina zona ha quedat el canvi.
3. Confirma. Comprova que has desfet només la part d'estils.css del tercer commit i que la resta continua al projecte.
4. Aconsegueix el mateix resultat amb git restore --source=... --staged --worktree i compara l'estat del directori de treball en tots dos casos.

1. En un repositori de proves, crea tres situacions alhora: un commit sense publicar, un canvi preparat amb git add, i un canvi només al disc.
2. Executa git reset --hard HEAD~1.
3. Recupera el commit fent servir el reflog.
4. Intenta recuperar el canvi preparat amb git fsck --lost-found i git cat-file -p.
5. Intenta recuperar el canvi que era només al disc. Documenta per què no és possible.
6. Repeteix tot l'exercici executant abans git stash push -u i explica què canvia.

Solució 1:

El commit ha sortit de la branca i el seu contingut és preparat (M i A a la primera columna). I aquí hi ha un detall fi: app.js apareix una sola vegada perquè l'índex conté tant el del commit desfet com la teva modificació sense confirmar encara fora... en realitat la modificació d'app.js continua al directori de treball, i l'índex té la versió del commit desfet. Comprova-ho:

Res no s'ha perdut: les dues capes són intactes i separades.

La branca ha tornat al seu lloc, però la modificació d'app.js ha desaparegut: --hard l'ha sobreescrita. ORIG_HEAD torna la posició de la branca, no la teva feina en curs. És exactament l'advertiment de l'apartat 8.

notes.txt no és a l'índex: Git no el segueix. reset opera sobre HEAD, l'índex i els fitxers que Git coneix; un fitxer sense seguiment li és invisible. Per esborrar-lo cal git clean (apartat 7).

Solució 2:

Amb una ruta, reset mai no toca el directori de treball ni mou la branca; --hard implica totes dues coses, així que és contradictori. Git ho rebutja en lloc de fer alguna cosa a mitges.

Clau: el fitxer al disc continua sent v3. Només l'índex té v1. Per això git diff (treball vs índex) mostra el canvi invers. I la branca no s'ha mogut:

app.js conserva v4, index.html conserva v3 (el que va aportar c3), i només estils.css ha tornat enrere. S'ha desfet una tercera part d'un commit.

Però atenció: el fitxer al disc continuava sent v3 en confirmar. El commit diu v1 i el disc diu v3, així que ara hi ha una modificació pendent. Aquesta asimetria és justament el que evita restore:

Índex i directori de treball coincideixen. Aquesta és la diferència pràctica: reset -- <ruta> només prepara; restore --staged --worktree prepara i escriu al disc. Per a l'ús diari, restore és més predictible.

Solució 3:

Tot fora: el commit, el fitxer preparat i la modificació al disc.

Recuperat íntegre.

El git add el va salvar. En preparar el fitxer, Git va crear el blob i el va escriure a .git/objects. El reset --hard va treure la referència des de l'índex, però l'objecte s'hi va quedar.

Només hi ha un objecte penjant, el de l'add. La línia CANVI NOMES AL DISC no existeix enlloc de .git. Mai no se'n va calcular el hash, mai no es va comprimir, mai no es va escriure. Git no pot recuperar una cosa de la qual no va tenir mai notícia. Les úniques vies reals serien l'historial local del teu editor (VS Code, IntelliJ i Vim amb undofile el desen) o una còpia de seguretat del sistema de fitxers.

Tot intacte, inclòs el fitxer sense seguiment gràcies a -u. El desament temporal va convertir les tres capes en commits ocults dins de la base de dades i, per tant, en una cosa recuperable fins i tot si s'hagués esborrat el desament (lliçó 09-04).

Un segon de git stash push -u compra la diferència entre "he perdut dues hores" i "no ha passat res".

reset deixa de fer por tan bon punt s'entén que fa dues coses amb el mateix nom.

• git reset <commit> mou la branca. No esborra commits: reescriu un fitxer de 41 bytes. Els commits que deixen de ser assolibles continuen íntegres a la base de dades.
• Els tres modes es distingeixen per fins on arriben: --soft només mou HEAD; --mixed (per defecte) a més reescriu l'índex; --hard a més sobreescriu el directori de treball. Només --hard destrueix alguna cosa, i el que destrueix són els canvis sense confirmar, no els commits. Els fitxers sense seguiment no els toca.
• --keep és el --hard prudent: avorta en lloc de trepitjar la teva feina local.
• git reset <commit> -- <ruta> és una altra operació: mai no mou la branca, mai no toca el disc, només omple l'índex. Per això --hard amb rutes és un error.
• Per a la feina diària, git restore: --staged per despreparar (no perd res), sense opcions per descartar al disc (destrueix), --source per portar d'un altre commit i -p per fer-ho tros a tros.
• git clean és l'única ordre d'aquest mòdul sense xarxa de seguretat, perquè el que mai no es va confirmar no és a .git/objects. -n abans que -f, sempre; -x mereix llegir-se dues vegades; git stash push -u ho converteix tot en recuperable.
• ORIG_HEAD desfà l'últim reset, merge, rebase o pull. Només desa una posició.
• I la decisió, en una pregunta: està publicat? Si no, reset, --amend o rebase -i. Si sí i la branca és compartida, revert (lliçó 05-06), sense excepcions.

Queda pendent el cas que la taula de decisió despatxa amb un "veure 09-03": què fer quan allò que s'ha embolicat no és dins del teu repositori, sinó entre el teu repositori i el servidor. El push rebutjat, el missatge de branques divergents, el company que va reescriure l'historial publicat i et va deixar amb feina penjant d'una base que ja no existeix.

Tot això, i el tancament de la promesa que vam deixar oberta a la lliçó 04-05, a la lliçó 09-03: Resolent Divergències amb el Remot.