La lliçó anterior va tancar el desfer local: reset, restore, clean, i una taula de decisió que acabava amb una fila remetent aquí. Aquesta lliçó s'ocupa de tot el que passa entre el teu repositori i el servidor, i tanca la promesa que va quedar oberta a la lliçó 04-05, on vam veure el rebuig non-fast-forward i només vam donar la sortida bàsica.

El problema té un nom i una definició precisa: divergència. I té una fama de complicat que no es mereix, perquè tan bon punt es dibuixa el graf la solució sol ser evident. El que confon és que el mateix estat es presenta amb quatre missatges diferents segons com el descobreixis: un status que diu "have diverged", un pull que es nega a decidir, un push rebutjat, o un company avisant que li han desaparegut commits.

Veurem que els quatre són la mateixa situació, que hi ha exactament tres maneres de sortir-ne, i que l'elecció entre les tres depèn d'una sola pregunta: de qui és aquesta branca?

I al final, el cas seriós: què fer quan qui va reescriure l'historial publicat va ser un altre, i tu tens dos dies de feina recolzats en una base que ja no existeix.

1. Què significa exactament "han divergit"
2. Mesurar la divergència
3. Els quatre missatges de la mateixa situació
4. Les tres polítiques de pull i quina triar
5. Com s'arriba a una divergència
6. El push rebutjat: diagnòstic i sortides
7. --force-with-lease i per què de vegades no protegeix
8. Quan el remot va reescriure i tu tens feina a sobre
9. Recuperar la branca remota anterior amb origin/branca@{1}
10. Històries no relacionades: --allow-unrelated-histories
11. Coordinació: què cal dir i quan

Dues branques han divergit quan cadascuna té commits que l'altra no té. Formalment: existeix un ancestre comú, i des d'ell surten dos camins diferents.

El teu main té dos commits que el servidor no té. El servidor en té tres que tu no tens. L'ancestre comú és 4f8a2e6.

Compara-ho amb els dos casos que no són divergència:

La paraula clau és decidir. Una divergència no és un error: és una situació en què Git no pot saber què vols i es nega a inventar-s'ho. Tot el que segueix són maneres de prendre aquesta decisió.

Recuperant la lliçó 03-01: l'ancestre comú és el que Git calcula amb git merge-base, i és la base de la fusió a tres bandes. El pots veure directament:

Abans de resoldre, mesura. Aquestes ordres no modifiquen res.

fetch actualitza origin/main sense tocar el teu main (lliçó 04-04). Sense això, estàs raonant sobre una foto vella del servidor.

Els tres punts són fonamentals: A...B és la diferència simètrica, els commits que són en una branca però no en l'altra. --left-right els separa per costat.

Amb la branca de seguiment configurada (lliçó 04-06), n'hi ha prou amb:

Això és el que de debò permet decidir:

< és el costat esquerre (el teu main), > el dret (origin/main).

I la pregunta que decideix si hi haurà conflictes:

Si els conjunts de fitxers no se solapen, la integració serà neta.

Segons com arribis a la divergència, Git te l'explica de manera diferent. Reconèixer-les totes és mitja lliçó.

És el diagnòstic pur. Els números coincideixen amb rev-list --left-right --count.

Des de Git 2.27, pull es nega a triar per tu:

Això és bo. Abans, pull feia una fusió silenciosa i omplia l'historial de commits "Merge branch 'main' of git.exemple.cat..." que ningú no havia demanat. Ara t'obliga a tenir una política, i això és l'apartat 4.

És la mateixa informació amb menys paraules: hi ha divergència i la teva política diu "no decideixis per mi". No és una fallada (lliçó 04-04, error 3).

O, en la seva variant més alarmant:

Totes dues diuen el mateix: el servidor té commits que tu no tens, i acceptar el teu enviament els deixaria inassolibles. És una protecció del servidor, no una fallada teva. És l'apartat 6.

git pull és fetch + integració (lliçó 04-04). La política decideix quina integració.

Visualment, sobre el mateix punt de partida:

La configuració recomanada per a la majoria de la gent:

O, si el teu equip treballa amb branques curtes i vol historial lineal (que és el que fa l'Ana a gestor-tasques):

rebase.autoStash evita el "cannot pull with rebase: You have unstaged changes", que és la queixa més freqüent contra pull --rebase.

La regla d'or continua vigent (lliçó 05-01): pull --rebase reescriu els teus commits locals, que encara no has publicat. Això és legítim. El que no s'ha de fer mai és rebasar commits que ja són al servidor i altres poden tenir.

I un ajust que evita un error clàssic:

Si tenies commits fixup! pendents (lliçó 05-02), no s'aixafaran per sorpresa durant un pull. Comprova-ho a la teva configuració: si el tens activat sense saber-ho, un pull --rebase et pot reorganitzar commits.

Entendre la causa importa, perquè determina quina de les sortides és correcta.

L'Ana va confirmar en local mentre el Bruno publicava el seu. Ningú no ha fet res malament. És el funcionament normal d'un sistema distribuït amb diverses persones.

Sortida: integrar (merge o rebase, segons la política) i enviar. Sense drama.

La Carla va publicar GT-247, es va adonar d'una errada al missatge i va executar git commit --amend.

Què ha passat. --amend no modifica el commit: en crea un de nou amb un hash diferent i mou la branca (lliçó 09-01, apartat 5.3). El commit original continua al servidor. Local i remot tenen ara un commit cadascun que l'altre no té: divergència d'1 i 1.

Sortida: si la branca és només seva, push --force-with-lease. Si no, cal integrar, i el resultat és lleig (el commit apareixeria dues vegades).

El Bruno va fer git reset --hard HEAD~2 sobre una branca publicada per "treure dos commits", i després va treballar dues hores més.

Divergència de 2 i 2. I aquí hi ha una decisió de fons: els commits C i D han de desaparèixer del projecte, o no?

Sortida: si han de desaparèixer i la branca és seva, --force-with-lease. Si la branca és compartida, la resposta correcta era git revert (lliçó 05-06) i no reset; ara toca integrar i revertir.

El Diego va fer un rebase -i sobre main per "netejar l'historial" i va forçar el push. Tots els qui tenien main baixat es troben amb una divergència que no han provocat.

És el cas seriós, i té apartat propi: el 8.

L'Ana i la Carla treballen alhora a GT-241. Totes dues fan pull --rebase. Cada rebase reescriu els commits de l'altra. El resultat és una espiral de commits duplicats que es resol malament.

Sortida: en branques realment compartides, pull.rebase false. La política ha de ser per branca, no per costum.

Aquest és el tancament del que es va prometre a la lliçó 04-05.

Amb aquestes quatre respostes ja saps quina sortida correspon.

Amb pull configurat:

Si apareixen conflictes durant el rebase, la mecànica és la de la lliçó 05-01, inclosa la inversió d'ours/theirs. I si t'angoixes:

Només si es compleixen les tres condicions:

1. La branca és de funcionalitat i ningú més no la fa servir.
2. El que hi ha al servidor són versions antigues dels teus propis commits.
3. Has comprovat el punt 3 del diagnòstic i no hi ha commits d'una altra persona.

El + al davant indica que ha estat un enviament forçat.

Mai --force a seques. La diferència és l'apartat 7.

De vegades la resposta correcta és no forçar i no integrar, sinó publicar en un altre lloc:

Especialment útil si la branca té una pull request oberta amb comentaris de revisió (lliçó 07-02): forçar pot deixar els comentaris orfes. Publicar una branca nova ho conserva tot i permet comparar amb git range-diff (lliçó 07-02).

Recordant la lliçó 04-05: --force-with-lease només força si el servidor és on tu creus que és. Compara la punta remota real amb la teva còpia local de la branca de seguiment (refs/remotes/origin/GT-241).

Aquest stale info significa: "el servidor no és on el teu origin/GT-241 diu; algú ha publicat alguna cosa des del teu últim fetch". És exactament la protecció funcionant: t'ha evitat destruir la feina d'un altre.

I aquí hi ha el detall que gairebé ningú no coneix, i que cal entendre bé:

Si fas git fetch just abans del --force-with-lease, la protecció desapareix.

Perquè fetch actualitza origin/GT-241 amb el que hi ha al servidor ara mateix, inclosos els commits nous del teu company. El teu "arrendament" (lease) passa a coincidir amb la realitat, la comprovació passa, i forces a sobre de feina que no has vist mai.

El pitjor és que és una seqüència raonable: "actualitzaré abans de forçar" sona a bona pràctica. I molts IDE fan fetch automàticament en segon pla, així que et pot passar sense que tu escriguis l'ordre.

Git 2.30 va afegir l'opció que arregla el forat:

--force-if-includes comprova, a més, que els commits remots que sobreescriuràs estan incorporats al teu historial local, mirant el teu reflog. És a dir: exigeix que hagis vist i integrat el que estàs a punt de reemplaçar, no només que ho hagis baixat.

Configura-ho com a comportament per defecte:

Amb això, cada --force-with-lease que executis porta la comprovació extra automàticament. És una línia de configuració que elimina una classe sencera d'accidents.

I la variant explícita, quan vols ser absolutament precís:

Verbós, però no hi ha manera d'equivocar-se.

Aquest és el cas seriós, i el que produeix més pànic. Es mereix el procediment complet.

La situació. El Diego va fer un rebase -i sobre main per netejar l'historial i va forçar el push. L'Ana tenia main baixat i, a sobre, tres commits de GT-241 que encara no havia publicat.

El primer: no has perdut res. Els teus commits continuen al teu repositori, íntegres. I els commits antics de main també els tens tu en local, encara que el servidor ja no els tingui. De fet, el teu clon és ara l'única còpia de la versió anterior, i això et dona una posició sòlida.

Els missatges es repeteixen a les dues branques, amb hashos diferents. Aquest és el patró inequívoc d'un historial reescrit. Confirma-ho:

git range-diff (lliçó 07-02) compara dues sèries de commits i diu si el contingut és el mateix:

Els dos primers són idèntics (=); el tercer va canviar (!) i t'ensenya exactament què. Aquesta és la informació que necessites abans de decidir res.

Dos segons. A partir d'aquí, res del que facis no és irreversible.

L'ordre que resol exactament això és el --onto de la lliçó 05-01. La seva forma és:

que es llegeix: "agafa els commits de <branca> que siguin després de <base-antiga> i reaplica'ls sobre <nova-base>".

En el nostre cas:

• Nova base: origin/main (l'historial nou).
• Base antiga: 7d3a8f4 (el main vell del qual penjava la teva branca).
• Branca: GT-241.

Els teus tres commits, amb hashos nous, sobre la base nova. Ni un commit duplicat.

Com trobar la base antiga si no la tens anotada:

El teu main local encara té la versió vella. Com que no tenies res propi a main (tota la teva feina era a GT-241), simplement alinea'l:

Si sí que tenies commits propis a main, no facis això: treu-los primer a una branca (git branch els-meus-commits-main) i trasplanta'ls amb el mateix --onto.

Tres =: el contingut dels teus commits és idèntic al d'abans del trasplantament. No s'ha perdut ni alterat res. Ara pots esborrar la còpia amb tranquil·litat:

I executa les proves abans de publicar: el rebase ha reaplicat el teu codi sobre una base diferent, i encara que no hi hagi hagut conflictes, hi pot haver incompatibilitats semàntiques.

Si els teus commits de GT-241 ja eren al servidor, després del rebase la teva branca diverge d'origin/GT-241. Com que GT-241 és teva:

Un detall que salva situacions i que gairebé ningú no coneix: les branques de seguiment remotes també tenen reflog.

Dues coses valuosíssimes en aquesta sortida:

1. forced-update és la prova que algú va reescriure l'historial publicat. Si dubtaves de què va passar, allà tens l'evidència amb la seva data.
2. origin/main@{1} és on era el main del servidor abans de la reescriptura.

Això és el que permet reconstruir el que el servidor tenia abans, i és la raó per la qual, quan algú força i destrueix feina, qualsevol company que tingués la branca baixada la pot tornar:

I també amb dates:

Aquest és exactament el mecanisme del reflog, el tractament complet del qual —inclosa la sintaxi @{n} davant de @{temps} i els límits de caducitat— és la lliçó 09-04.

Què significa. Les dues branques no tenen cap ancestre comú. No és una divergència: és que són dos arbres genealògics completament independents, cadascun amb el seu propi commit arrel.

Abans de res, comprova que és el cas benigne:

Si el remot només té el commit inicial de la plataforma:

Probablement entrarà en conflicte a README.md: resol-lo amb normalitat (lliçó 03-05) i confirma.

Si el remot té el projecte de debò i la teva història local és la sobrera:

I si algú ha publicat un altre projecte a sobre del vostre, això és un incident: no fusionis res, avisa l'equip, i fes servir origin/main@{1} de l'apartat 9 (o el clon de qualsevol company) per restaurar. La lliçó 09-05 tracta l'ús d'altres clons com a còpia de seguretat.

No executis mai --allow-unrelated-histories "perquè Git es queixa". Aquesta negativa és una comprovació de seny molt útil: Git t'està dient que aquestes dues coses no tenen res a veure. Esbrina per què abans de saltar-te-la.

La part no tècnica, que és la que més temps estalvia.

Abans de reescriure alguna cosa compartida:

1. Avisa abans, no després. Un missatge de trenta segons al canal de l'equip: "Forçaré main a les 16:00 per treure el bolcat de la base de dades de l'historial. No feu pull fins que avisi."
2. Digues què han de fer els altres. Encara que per a tu sigui obvi, no ho és per a qui està en una altra cosa:

   Després de l'avís, cadascú:
     git fetch origin
     git switch main
     git reset --hard origin/main
   Si teniu branques amb commits propis, aviseu-me abans de tocar res
   i fem el rebase --onto junts.
   

3. Fes-ho en un moment de poca activitat. Mai un divendres a la tarda, mai durant una entrega.
4. Confirma quan acabi. El silenci genera pull a cegues.

Quan ja ha passat i no vas avisar:

1. Avisa igualment, com abans millor. El cost de dir "he forçat main, no feu pull" al cap de cinc minuts és zero. Al cap de cinc hores és una tarda de feina per a tres persones.
2. Ofereix el procediment de l'apartat 8, no un "arregleu-ho".
3. Si has destruït feina aliena, l'apartat 9 la recupera des de qualsevol clon de l'equip. No s'ha perdut.

Prevenció estructural (lliçó 07-06):

Una branca protegida converteix tot aquest apartat en innecessari. Si main no accepta --force, el problema no pot passar. És la mesura més rendible de la lliçó.

I en local, una protecció personal:

Error 1: respondre a un push rebutjat amb --force. El rebuig significa que el servidor té commits que tu no tens. Forçar els destrueix. Diagnostica primer: git log --oneline HEAD..@{u} diu de qui són.

Error 2: raonar sobre origin/main sense haver fet fetch. origin/main és una foto local que pot tenir hores. Tot diagnòstic comença per git fetch.

Error 3: git fetch just abans de --force-with-lease. Anul·la la protecció. Fes servir --force-if-includes, o configura-ho amb push.useForceIfIncludes true.

Error 4: fer servir pull --rebase en una branca que una altra persona també té. Reescriu commits publicats i genera duplicats en cadena. La política ha de ser per branca, no per costum.

Error 5: fer --allow-unrelated-histories sense mirar què hi ha a l'altre costat. Pots acabar fusionant un altre projecte sencer dins del teu. Mira git log origin/main primer.

Error 6: git reset --hard origin/main sense comprovar què tens al davant. git log --oneline @{u}..HEAD costa un segon i et diu exactament què llençaràs.

Error 7: refer la feina a mà després d'una reescriptura aliena. git rebase --onto la trasplanta en una ordre i range-diff demostra que no s'ha alterat res.

Error 8: forçar una branca amb una pull request oberta plena de comentaris. Pot deixar la revisió òrfena. Considera publicar una branca nova.

Error 9: no avisar. El cost tècnic d'una reescriptura compartida és petit; el cost social de no anunciar-la, enorme.

Consell 1: git status -sb com a reflex. Una línia que diu [ahead N, behind M] i resol la meitat dels dubtes.

Consell 2: pull.ff only com a valor global. T'obliga a mirar abans d'integrar, i evita commits de fusió que ningú no va demanar.

Consell 3: push.useForceIfIncludes true. Una línia de configuració que elimina el forat del --force-with-lease.

Consell 4: git range-diff abans i després de qualsevol reescriptura. És la prova objectiva que el contingut no ha canviat.

Consell 5: recorda origin/branca@{1}. L'historial anterior del servidor continua al teu reflog remot, i amb ell es restaura el que un altre va destruir.

Consell 6: protegeix main al servidor. És l'única solució que fa impossible el problema, en lloc de tractar-lo.

1. Munta un remot local amb git init --bare i clona'l dues vegades (simulant l'Ana i el Bruno).
2. Des del clon del Bruno, fes dos commits i publica'ls.
3. Des del de l'Ana, sense fer fetch, fes dos commits diferents.
4. Executa git fetch i mesura la divergència amb git status -sb, git rev-list --left-right --count i git log --left-right --oneline.
5. Prova git push i transcriu el missatge exacte.
6. Resol-ho amb pull --rebase i comprova amb git log --graph que l'historial ha quedat lineal.
7. Repeteix tot l'exercici amb pull --no-rebase i compara els dos grafs resultants.

1. Amb el mateix muntatge, fes que l'Ana publiqui un commit a GT-241.
2. L'Ana executa git commit --amend sobre aquest commit (sense publicar encara).
3. Mentrestant, el Bruno publica un commit nou a GT-241.
4. L'Ana executa git push --force-with-lease. Anota el resultat i explica'l.
5. L'Ana executa git fetch i torna a intentar-ho. Anota el resultat i explica per què ha canviat.
6. Comprova que el commit del Bruno ha desaparegut del servidor i recupera'l fent servir origin/GT-241@{1} des del clon del Bruno.
7. Repeteix el pas 5 amb --force-if-includes i comprova que ara sí que protegeix.

1. Munta un remot amb tres commits a main i clona'l dues vegades.
2. Des del clon de l'Ana, crea GT-241 sobre main amb tres commits propis (sense publicar-la).
3. Des del clon del Diego, fes git rebase -i sobre main per modificar el missatge del segon commit, i força el push.
4. L'Ana fa fetch i diagnostica la situació amb git log --graph --all i git range-diff.
5. L'Ana trasplanta GT-241 amb git rebase --onto i alinea el seu main.
6. Verifica amb range-diff que els seus tres commits són idèntics en contingut.
7. Comprova a git reflog show origin/main que queda registrat el forced-update.

Solució 1:

Lineal, sense bifurcacions. Els seus dos commits tenen hashos nous (b52c9d1 → 8f2d6a1): el rebase els ha recreat sobre la base nova.

Solució 2:

La protecció ha funcionat. L'origin/GT-241 de l'Ana apunta al seu commit original; el servidor és al commit del Bruno. Com que no coincideixen, Git es nega.

Ha passat. I ha destruït el commit del Bruno. El fetch va actualitzar origin/GT-241 al commit del Bruno; l'"arrendament" va passar a coincidir amb la realitat; la comprovació es va satisfer. L'Ana no va veure mai la feina del Bruno i tot i així la va sobreescriure.

En realitat el Bruno ni tan sols necessita el reflog: té el commit a la seva branca local. El seu GT-241 local continua intacte:

I per tornar-lo al servidor caldria integrar-lo amb la versió esmenada de l'Ana —un cherry-pick del commit del Bruno sobre la branca nova (lliçó 05-03)—, coordinant-ho entre tots dos.

Ara sí que protegeix, fins i tot després del fetch. La comprovació addicional exigeix que els commits remots que se sobreescriuran estiguin incorporats a l'historial local de l'Ana, no només baixats. I no ho estan: mai no els va integrar.

Solució 3:

Anota aquest 7d3a8f4: és la base antiga.

Dues línies paral·leles amb els mateixos missatges: historial reescrit.

Només va canviar un missatge; el contingut és idèntic. Diagnòstic complet en una ordre.

Tres =. Contingut idèntic, base nova, zero commits duplicats.

forced-update amb la seva data, i origin/main@{1} guardant l'historial anterior del servidor. Si hagués calgut restaurar-lo, allà era.

Les divergències deixen de fer por tan bon punt es veuen com el que són: una situació en què Git no pot decidir per tu.

• Divergir significa que cada branca té commits que l'altra no té. Es mesura amb git status -sb i amb git rev-list --left-right --count main...origin/main, i s'entén mirant els dos costats amb git log --left-right. Tot diagnòstic comença per git fetch.
• Els quatre missatges són la mateixa situació: el "have diverged" del status, el "You have divergent branches" del pull, el "Not possible to fast-forward" del pull.ff only i el non-fast-forward del push.
• Tres polítiques de pull: merge per a branques realment compartides, rebase per a les teves, ff-only quan prefereixes decidir a mà. L'elecció és per branca, no per costum.
• Al push rebutjat s'hi respon diagnosticant, no forçant: git log --oneline HEAD..@{u} diu de qui són els commits del servidor. Si són d'un altre, s'integra. Si són versions velles dels teus i la branca és només teva, es força amb --force-with-lease.
• --force-with-lease no protegeix si has fet fetch just abans, perquè l'arrendament s'actualitza amb el que encara no has vist. --force-if-includes ho arregla; push.useForceIfIncludes true ho deixa posat per sempre.
• Quan un altre reescriu l'historial publicat i tu tens feina a sobre, el procediment és: fer còpia amb git branch, trasplantar amb git rebase --onto <nova-base> <base-vella> <branca>, alinear main amb reset --hard origin/main, i verificar amb git range-diff que el contingut no ha canviat.
• Les branques remotes també tenen reflog. origin/main@{1} guarda on era el servidor abans de la reescriptura, i forced-update és l'evidència que va passar. Amb això, qualsevol clon de l'equip pot restaurar el que es va destruir.
• refusing to merge unrelated histories no és divergència: són dos arbres sense ancestre comú. Mira què hi ha a l'altre costat abans de fer servir --allow-unrelated-histories.
• I el que més estalvia: avisar abans, i protegir main al servidor perquè el problema no pugui passar.

Queda una idea que ha aparegut a gairebé tots els apartats sense desenvolupar-se: el reflog. Ha estat la font de l'ORIG_HEAD de la lliçó anterior, de l'origin/main@{1} d'aquesta, i de la promesa que portem oberta des de la lliçó 03-06 ("-D és recuperable") i la 05-01 ("un rebase desastrós es pot desfer").

Toca desenvolupar-lo sencer: què és exactament, on viu, quant dura, com es llegeix, i el receptari complet de recuperació —el reset --hard que es va emportar tres dies, la branca esborrada amb -D, el rebase que va sortir malament, el desament temporal eliminat— més què fer quan ni tan sols el reflog no n'hi ha prou.

Continua a la lliçó 09-04: Recuperant Confirmacions Perdudes.