L'Ana i en Bruno tenen dues funcionalitats acabades i provades, cadascuna a la seva branca. I tanmateix main —el projecte de debò, el que es publica— continua exactament on era fa una setmana, a c5d9b1e. Aïllar la feina era la meitat del problema; aquesta lliçó resol l'altra meitat.

Fusionar (merge) és l'operació de portar la feina d'una branca a una altra. És la raó de ser de les branques: si no es poguessin tornar a ajuntar, aïllar la feina no serviria de res.

Git distingeix dos escenaris molt diferents en fusionar, i confondre'ls és l'origen de la majoria de dubtes. En un, no hi ha res a fusionar de debò i n'hi ha prou de moure un punter. En l'altre, hi ha dues línies de treball divergents i cal crear un commit nou amb dos pares. Els veurem tots dos en directe, entendrem quan es produeix cadascun, i aprendrem a forçar o prohibir cada comportament quan ens interessi.

En aquesta lliçó totes les fusions sortiran bé a la primera. Quan dues persones toquen les mateixes línies apareixen els conflictes, i aquests tenen lliçó pròpia (03-05).

1. Com es fusiona: sempre des de la branca de destinació
2. Escenari 1: fast-forward, el punter avança
3. Desfer una fusió local
4. --no-ff: forçar el commit de fusió
5. Escenari 2: la fusió a tres bandes
6. L'ancestre comú i git merge-base
7. Anatomia del commit de fusió
8. Llegir un historial amb fusions
9. --ff-only: prohibir els commits de fusió

Abans de res, la regla que evita el 90 % dels errors de principiant:

Et situes a la branca que vol rebre la feina i fusiones la que l'aporta.

git merge només mou la branca on ets. La branca que anomenes com a argument no es toca en absolut: continua apuntant exactament al mateix commit abans i després.

Aplicat al cas de l'Ana: vol que main rebi el comptador de tasques.

A l'inrevés —ser a funcionalitat/comptador-tasques i fer git merge main— és una operació diferent i vàlida, però significa una altra cosa: portar a la meva branca de treball l'últim de main, una cosa que es fa per mantenir-se al dia. Canviar l'ordre per descuit és un clàssic. Abans de fusionar, comprova on ets:

Situació de partida:

Fixa't en la relació entre main i funcionalitat/comptador-tasques. main és a c5d9b1e, i c5d9b1e és un avantpassat directe de 9d1e4b7. Amb el vocabulari de la lliçó 03-01: main està endarrerida, no ha divergit. No té cap commit propi que la branca de l'Ana no tingui.

En aquesta situació, «fusionar» és una paraula massa gran. No hi ha res a combinar: tot el que hi ha a main ja està contingut a l'altra branca. N'hi ha prou d'avançar el punter de main fins a 9d1e4b7.

Analitzem la sortida línia a línia:

• Updating c5d9b1e..9d1e4b7: d'on a on ha mogut main.
• Fast-forward: el nom de l'escenari. No s'ha creat cap commit.
• El resum de fitxers: els canvis acumulats dels dos commits de l'Ana, en el mateix format de git diff --stat que ja coneixes.

Abans i després, al disc:

Això és tot el que ha passat: 41 bytes reescrits. No hi ha commit nou, no hi ha objectes nous, no hi ha res a calcular.

L'historial resultant:

Una línia perfectament recta. Les dues branques apunten ara al mateix commit.

I aquí hi ha el detall que cal sospesar: mirant aquest historial, és impossible saber que hi va haver una branca. 6f2b9d4 i 9d1e4b7 semblen dos commits normals fets directament sobre main. La informació que formaven una unitat de treball —una funcionalitat— s'ha perdut.

De vegades això és exactament el que vols (historial net i lineal). D'altres vegades no. Per al segon cas hi ha --no-ff, però abans hem de desfer el que hem fet.

L'Ana s'ha quedat amb el dubte i vol provar l'altra manera. Com que la fusió és local i encara no ha sortit del seu portàtil, desfer-la és trivial: n'hi ha prou de tornar el punter de main on era.

Tot com era. Els dos commits de l'Ana no s'han perdut perquè funcionalitat/comptador-tasques continua apuntant-hi: són perfectament assolibles.

Tres advertiments sobre el que acabem de fer:

• git reset --hard és una eina esmolada. Mou el punter de la branca i sobreescriu el directori de treball, descartant qualsevol canvi sense confirmar. L'estudiarem amb tot detall a la lliçó 09-02.
• Aquí és segur perquè la feina està protegida per una altra branca i perquè no hi havia res sense confirmar.
• Només val per a fusions locals. Si la fusió ja s'hagués compartit amb la resta de l'equip, moure el punter cap enrere causaria problemes als altres; allà l'eina correcta és git revert (lliçó 05-06). Com que tot aquest mòdul passa en un únic repositori local, no tenim aquest problema.

Una drecera útil: Git desa automàticament la posició anterior a la referència ORIG_HEAD just abans d'operacions com merge o reset. Així que això hauria estat equivalent sense necessitat de recordar el hash:

L'Ana ho torna a intentar, aquesta vegada demanant explícitament que es creï un commit de fusió encara que no calgui:

Git obre l'editor amb un missatge proposat:

L'Ana amplia la primera línia perquè digui alguna cosa útil i desa:

Fixa't en la diferència: ara diu Merge made by the 'ort' strategy en lloc de Fast-forward. S'ha creat un commit.

El commit 8d4e6b2 no aporta cap canvi de codi: el contingut resultant és idèntic al de 9d1e4b7. El que aporta és informació sobre l'estructura de la feina: diu que aquells dos commits formaven una unitat i quan es va integrar al projecte.

Molts equips ho fixen a la configuració per no haver-se'n de recordar:

Amb això, totes les fusions crearan commit de fusió. Una variant més matisada, molt estesa, és deixar-ho per branca o simplement escriure --no-ff quan s'integra una funcionalitat i permetre el fast-forward per a la resta.

És una decisió d'equip, no una qüestió tècnica: l'important és que tothom faci el mateix. Hi tornarem al mòdul 8.

Ara l'Ana integra la feina d'en Bruno. I la situació ha canviat completament:

main ja no és avantpassat de funcionalitat/filtre-pendents: té tres commits propis (els dos de l'Ana més la fusió) que la branca d'en Bruno no té. I la branca d'en Bruno en té tres més que main no té. Han divergit.

Aquí no val moure un punter. Git ha de combinar de debò dues versions diferents dels fitxers.

Git obre l'editor amb el missatge proposat —l'Ana l'accepta tal qual aquesta vegada— i respon:

(Al diagrama, filtre-pendents es dibuixa sortint de main; recorda que en realitat parteix de c5d9b1e, abans de la primera fusió.)

El projecte té per fi les dues funcionalitats. app.js conté el comptador de l'Ana i el filtre d'en Bruno, i cap dels dos no ha hagut de copiar res a mà.

Perquè Git fa servir tres versions de cada fitxer per decidir el resultat:

I la regla, línia a línia, és la que vam anticipar a la lliçó 03-01:

En aquest cas no hi ha hagut conflictes perquè l'Ana va tocar la capçalera i la lògica del comptador, mentre que en Bruno va afegir el filtre més avall i unes regles noves a estils.css. Zones diferents dels mateixos fitxers.

Fixa't en la conseqüència important: que dues persones toquin el mateix fitxer no provoca cap conflicte. El conflicte apareix quan toquen les mateixes línies (o línies molt properes) de maneres diferents. És una font de por innecessària molt estesa.

Git no et pregunta quin és l'ancestre comú: el calcula. I el pots calcular tu:

Efectivament: l'últim commit que les dues branques tenen en comú, el punt on es van separar.

Algunes variants útils:

Un 1 significa «no». Si donés 0, la fusió seria un fast-forward. És la comprovació exacta que fa git merge per decidir l'escenari, i resulta molt pràctica en scripts.

Fixa't en els tres punts. Ja vas veure a..b a la lliçó 02-06 (el que hi ha a b i no a a); a...b és la diferència simètrica: el que té cadascuna i l'altra no. És la manera natural de respondre a «en què es diferencien aquestes dues branques?».

Un truc molt utilitzat per veure què aporta una branca respecte al punt on es va separar, sense que aparegui tot el que ha avançat main mentrestant:

Amb tres punts a git diff, Git compara l'ancestre comú amb la punta de la segona branca. És a dir, mostra només el que ha fet en Bruno, ignorant el que hagi canviat a main des de llavors. És el que ensenyen les plataformes de revisió de codi quan mostren els canvis d'una proposta.

Un commit de fusió és un objecte commit normal i corrent amb una única peculiaritat: té més d'una línia parent. Recorda el model de dades de la lliçó 01-04, on vam veure que el camp parent es pot repetir.

Dues línies parent. I l'ordre importa moltíssim:

Aquell ordre és el que fa que la branca de destinació sigui sempre ^1 i la branca portada sigui ^2. Té conseqüències pràctiques concretes:

• git log --first-parent segueix només el primer pare i produeix un resum net del projecte principal.
• git revert -m 1 <fusio> desfà una fusió conservant la línia principal, indicant amb -m 1 quin dels pares és el «bo» (lliçó 05-06).
• És el motiu pel qual HEAD^ i HEAD~1 no són sinònims en un commit de fusió, cosa que ja es va apuntar a la lliçó 02-06.

Dues coses que sorprenen:

1. Apareix una línia Merge: amb els hashos abreujats dels dos pares. És l'indicador visual que ets davant d'una fusió.
2. No hi ha diff. Per defecte, git show i git log -p no mostren canvis als commits de fusió.

No és cap error. Un commit de fusió té dos pares, així que «el diff» és ambigu: respecte a quin? I, en una fusió neta com aquesta, respecte a qualsevol dels dos el resultat seria simplement tot el que aportava l'altra branca, que ja és als seus propis commits. Mostrar-ho duplicaria informació.

Si tot i així ho necessites:

--cc és l'opció realment valuosa i mereix que la recordis: en una fusió neta no mostra pràcticament res, però en una fusió amb conflictes resolts mostra exactament el que va decidir la persona, que és justament el que interessa auditar. La farem servir a la lliçó 03-05.

L'historial de main ja no és una línia recta, i val la pena saber mirar-lo des de dues altures diferents.

Vista completa, amb tot el detall:

Vista d'alt nivell, seguint només el primer pare:

Sis entrades en lloc d'onze. Aquest és l'historial des del punt de vista del projecte: què es va integrar a main i en quin ordre, sense el detall intern de cada funcionalitat. Per a un responsable de producte o per redactar unes notes de versió, és infinitament més útil que la vista completa.

I aquí es veu per què val la pena escriure bons missatges als commits de fusió: Fusiona el comptador de tasques pendents informa; Merge branch 'funcionalitat/filtre-pendents' obliga a endevinar.

Altres filtres relacionats:

--no-merges és especialment útil combinat amb --author per veure el que ha escrit realment una persona sense comptar les seves integracions.

L'oposat de --no-ff. Amb --ff-only, Git fusiona només si pot fer-ho avançant el punter; si calgués un commit de fusió, s'hi nega i no toca res:

Per a què serveix negar-se a fusionar? Per garantir un historial lineal. Hi ha equips que no volen veure ni un sol commit de fusió a main i prefereixen que qui integra posi primer la seva branca al dia (amb rebase, que veurem a la lliçó 05-01) i després fusioni en fast-forward.

També és una xarxa de seguretat excel·lent contra fusions accidentals. I de fet ja el tens actiu sense saber-ho: a la lliçó 01-06 vas configurar

que aplica exactament aquesta política a git pull (que, com veurem al mòdul 4, és una obtenció seguida d'una fusió). La configuració equivalent per a git merge seria:

Un parell d'opcions més que convé conèixer:

--no-commit és especialment interessant i el reprendrem a la lliçó següent, quan parlem d'estratègies: permet inspeccionar i ajustar el resultat de la fusió abans de segellar-lo.

Error 1: fusionar en la direcció equivocada. Ser a funcionalitat/comptador-tasques i executar git merge main quan el que volies era el contrari. La branca de funcionalitat rep main, main no se n'assabenta, i després no entens per què el projecte continua igual. Comprova sempre amb git branch --show-current abans de fusionar.

Error 2: creure que fusionar mou les dues branques. git merge mou només la branca on ets. Després d'integrar funcionalitat/filtre-pendents a main, aquella branca continua exactament a b2e6d3f. Continua existint i continua apuntant al mateix; esborrar-la quan ja no calgui és tema de la lliçó 03-06.

Error 3: témer que fusionar dues branques que toquen el mateix fitxer doni conflicte. No en dona si toquen zones diferents. Git treballa línia a línia, no fitxer a fitxer.

Error 4: no entendre per què git show d'una fusió no mostra canvis. És el comportament per defecte i té sentit: el diff seria ambigu amb dos pares. Fes servir --cc per veure el que es va decidir a mà o --first-parent per veure el que la fusió va portar.

Error 5: deixar el missatge de fusió per defecte en integracions importants. Merge branch 'funcionalitat/x' no diu res que el graf no digui ja. En una vista --first-parent, aquell missatge és tota la informació disponible sobre la integració: aprofita'l per explicar què s'integra i per què.

Consell 1: comprova abans de fusionar què t'emportaràs. Dues ordres que costen un segon:

Consell 2: fusiona amb el directori de treball net. Git es nega a fusionar si hi ha canvis sense confirmar que es poguessin perdre, però fins i tot quan t'hi deixa, barrejar els teus canvis a mitges amb el resultat d'una fusió és una recepta per no saber què és teu i què ha portat la fusió.

Consell 3: fusiona sovint en la direcció «de main cap a la teva branca». Portar main a la teva branca de funcionalitat cada pocs dies manté la divergència petita i converteix els conflictes grossos en conflictes trivials. És la millor prevenció que existeix davant de la lliçó 03-05.

Consell 4: fes servir --first-parent per presentar la feina. Quan algú et pregunti «què ha entrat al projecte aquest mes?», git log --oneline --first-parent --since="1 month ago" dona la resposta exacta.

Crea un repositori nou i provoca deliberadament els dos escenaris:

1. Una fusió que sigui fast-forward.
2. Una fusió a tres bandes, sense conflictes.

Abans d'executar cada git merge, prediu amb git merge-base --is-ancestor quin dels dos passarà.

Sobre la fusió a tres bandes de l'exercici anterior, esbrina:

1. Els hashos complets dels seus dos pares, fent servir només ordres de lampisteria.
2. Quin dels dos era la branca de destinació.
3. Per què git show <fusio> no mostra cap diff i com veure'l igualment.
4. Quants commits mostra git log --oneline i quants git log --oneline --first-parent.

Per a cada situació, digues quina opció de fusió faries servir (--ff per defecte, --no-ff o --ff-only) i justifica-ho en una frase:

1. Integrar a main una funcionalitat de 12 commits desenvolupada durant dues setmanes.
2. Integrar una branca amb un únic commit que corregeix una errada al README.
3. Posar al dia la teva branca de funcionalitat amb l'últim de main, sabent que tu no has tocat main.
4. Un script d'integració contínua que ha de fallar si algú intenta introduir una fusió inesperada a main.

Solució 1:

Escenari fast-forward:

Predicció:

0 significa que main sí que és avantpassat de branca-ff: serà fast-forward.

Escenari a tres bandes:

Predicció:

1 significa «no»: main té ara un commit propi. Han divergit, caldrà commit de fusió.

Sense conflicte: cada branca va tocar un fitxer diferent.

Solució 2:

O de manera més directa:

Era main, que és on érem en fusionar. El segon pare és la punta de branca-3b.

Perquè amb dos pares el diff és ambigu. Per veure'l:

La segona vista omet el commit de la branca fusionada i mostra només la línia principal: primer commit, tercer.txt i la fusió.

Solució 3:

1. --no-ff. Dotze commits són una unitat de treball amb identitat pròpia. El commit de fusió documenta quan va entrar la funcionalitat i permet revertir-la sencera amb git revert -m 1. A més, a --first-parent apareixerà com una sola entrada.

2. Per defecte (fast-forward). Una errada no és una unitat de treball que mereixi un node al graf. Un commit de fusió aquí només afegeix soroll.

3. --ff-only. Si no has tocat main, la teva branca hauria d'estar simplement endarrerida i el fast-forward funcionarà. Si falla, és que hi havia divergència inesperada, i la fallada és una informació valuosa: t'avisa abans de crear una fusió que no esperaves.

4. --ff-only. És exactament el cas d'ús: convertir la política d'historial lineal en una comprovació automàtica que falla en lloc de crear el commit de fusió.

Ja saps ajuntar la feina que les branques mantenien separada:

• Es fusiona des de la branca de destinació: git switch main i després git merge <branca>. git merge mou només la branca on ets.
• Fast-forward: si la branca de destinació és avantpassada de la que fusiones, no hi ha res a combinar i Git es limita a avançar el punter. No es crea cap commit i l'historial queda lineal, a canvi de perdre la traça que hi va haver una branca.
• Fusió a tres bandes: si les branques han divergit, Git combina les tres versions de cada fitxer (base, ours, theirs) i crea un commit de fusió amb dos pares. Les línies que només va canviar un costat s'agafen d'aquell costat; les que van canviar tots dos de manera diferent són un conflicte.
• L'ancestre comú el calcula Git i el pots consultar amb git merge-base. --is-ancestor prediu l'escenari; la sintaxi a...b serveix per comparar dues branques pel seu punt de separació.
• El commit de fusió és un commit normal amb dues línies parent. L'ordre importa: ^1 és la branca de destinació i ^2 la portada. D'aquí --first-parent, git revert -m 1 i el fet que HEAD^ i HEAD~1 difereixin a les fusions. git show no mostra diff per defecte; fes servir --cc.
• --no-ff força el commit de fusió encara que no calgui, per documentar la integració; --ff-only el prohibeix, per garantir un historial lineal. Tots dos es poden fixar amb merge.ff.

main ja conté el comptador de tasques i el filtre de pendents. El projecte està sencer per primera vegada des que en Bruno s'hi va incorporar.

A les sortides d'aquesta lliçó ha aparegut una vegada i una altra una paraula que hem deixat passar: Merge made by the **'ort'** strategy. Què és ort? N'hi ha d'altres? Es poden triar?

Sí, i en alguns casos triar bé estalvia molta feina. A la lliçó següent, Estratègies de Fusió, veurem les estratègies que Git sap aplicar (ort, resolve, octopus, ours, subtree), les opcions d'estratègia amb -X —inclòs el parany clàssic de confondre l'estratègia ours amb l'opció -X ours—, el squash merge, que aixafa una branca sencera en un sol commit sense registrar la fusió, i una taula de decisió per saber quina forma d'integrar triar segons l'historial que vulguis acabar tenint.