Ciao, e benvenuto nella settima puntata della quattordicesima stagione. Nella scorsa puntata abbiamo visto i rami come etichette leggere, che permettono di dividere il lavoro in linee separate. Ma dividere è solo metà della storia: prima o poi, il lavoro fatto su un ramo va riunito con il resto. Oggi affrontiamo questa riunificazione, la fusione, e sfatiamo anche l'altro grande spauracchio di Git, quello che fa sudare freddo i principianti: i conflitti. Vedrai che, con il modello in testa, anche questi diventano comprensibili e gestibili.
Partiamo dal perché serve fondere. Ricordi il grafo che si biforca: da un certo punto, due linee di sviluppo divergono, magari perché tu hai lavorato su una nuova funzionalità in un ramo separato, mentre il lavoro principale è andato avanti per conto suo. A un certo punto, la tua funzionalità è pronta, e vuoi riportare il suo lavoro dentro la linea principale. Fondere significa proprio questo: prendere il lavoro fatto su una linea e integrarlo in un'altra, riunendo due percorsi che si erano separati. È il momento in cui i fiumi divisi tornano a confluire.
Vediamo come Git affronta una fusione. Per prima cosa guarda il grafo e trova il punto in cui le due linee si erano separate, il loro antenato comune, l'ultima istantanea che avevano prima di divergere. Da lì Git può vedere cosa è cambiato su ciascuna delle due linee. Poi prende i cambiamenti fatti su una linea e quelli fatti sull'altra, e cerca di combinarli in un'unica nuova istantanea che contenga il lavoro di entrambe. La fusione è questo: combinare due evoluzioni divergenti partendo dal loro antenato comune.
C'è un caso particolarmente semplice di fusione, comodo e frequente. A volte una delle due linee non è andata avanti affatto: solo l'altra ha lavorato. Allora non c'è nulla da combinare: basta far avanzare l'etichetta della linea ferma fino a raggiungere il lavoro dell'altra, come un'etichetta che scivola in avanti sui commit già fatti. Git chiama questo caso, con un'immagine efficace, un avanzamento veloce: non si crea nulla di nuovo, si sposta solo un'etichetta. È la fusione più indolore che ci sia.
Quando invece entrambe le linee hanno lavorato, si crea una vera fusione, e qui torna un concetto della quinta puntata. Git combina i due lavori in una nuova istantanea, e crea per essa un commit speciale: quel commit con due genitori di cui avevamo parlato. Questo commit di fusione ha due genitori, uno per ciascuna delle due linee che sta unendo, ed è il punto del grafo in cui i due fiumi tornano a confluire in uno solo. Da lì in avanti, la storia riprende unita, ma quel commit a due genitori resta lì a testimoniare che, in quel punto, due percorsi separati sono stati riuniti. È la confluenza fatta commit.
Ora arriviamo ai temuti conflitti, e voglio subito ridimensionare la paura. Nella maggior parte dei casi, Git riesce a combinare i due lavori da solo, senza problemi, perché le modifiche delle due linee riguardano parti diverse del progetto e non si pestano i piedi. Il conflitto nasce solo in una situazione precisa: quando le due linee hanno modificato esattamente la stessa parte dello stesso file, in modi diversi. In quel caso Git si trova davanti a due versioni contrastanti della stessa cosa, e non può decidere da solo quale sia quella giusta: non è capace di leggere nella tua mente quale delle due intendevi tenere. Il conflitto è esattamente questo: due modifiche incompatibili sullo stesso punto.
Ed ecco il cambio di prospettiva liberatorio, il cuore della puntata: un conflitto non è un errore, non è un guasto, non è qualcosa che hai rotto. È semplicemente Git che, onestamente, ti dice: qui ci sono due versioni diverse della stessa cosa, e io non so quale vuoi; decidi tu. È una richiesta di aiuto, non un rimprovero. Git ti sta consegnando la decisione perché è una decisione umana, che richiede di capire l'intenzione, cosa che una macchina non può fare. Risolvere un conflitto significa semplicemente guardare le due versioni in contrasto e scegliere, o combinarle, come vuoi tu. Una volta scelto, dici a Git che hai deciso, e la fusione si completa.
Voglio darti la mentalità giusta verso i conflitti. Invece di temerli come catastrofi, vedili come momenti normali del lavoro in gruppo, in cui due persone hanno toccato la stessa cosa e qualcuno deve dire l'ultima parola: piccole sovrapposizioni del lavoro collaborativo di cui parlavamo nella prima stagione. Con il modello in testa sai esattamente cosa succede: due modifiche sullo stesso punto, e Git che ti chiede di scegliere. Nessuna magia, nessun disastro: solo una decisione da prendere con calma.
Per oggi ci fermiamo qui. Fondere significa riunire il lavoro di due linee che si erano separate: Git trova il loro antenato comune, e combina i cambiamenti di entrambe in una nuova istantanea. Nel caso semplice dell'avanzamento veloce basta spostare un'etichetta; nel caso vero si crea un commit di fusione con due genitori, la confluenza fatta commit. I conflitti nascono solo quando le due linee toccano la stessa parte allo stesso modo, e non sono errori ma richieste oneste di decidere tu, che una macchina non può prendere. Con il modello in testa, non fanno più paura. Nella prossima puntata affrontiamo il tema più potente e delicato: riscrivere la storia. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.