Ciao, e benvenuto nella nona puntata della quattordicesima stagione. Finora abbiamo parlato di Git come se vivesse tutto sul tuo computer: le tue istantanee, i tuoi rami, la tua storia. Ma Git è nato per far collaborare persone diverse, sparse ovunque. Oggi scopriamo come, e capiamo una delle caratteristiche più profonde e sorprendenti di Git, quella che lo distingue dai sistemi che l'hanno preceduto: la sua natura distribuita. Il fatto che ogni copia sia una copia completa, e che i luoghi remoti siano solo altre copie con cui sincronizzarsi.
Partiamo da come funzionavano i vecchi sistemi, per apprezzare la novità. Prima di Git, molti sistemi per gestire le versioni erano centralizzati: c'era un unico server centrale che custodiva tutta la storia del progetto, e i singoli sviluppatori avevano sul proprio computer solo una fetta, una versione parziale, l'ultima istantanea su cui lavorare. Per fare quasi tutto, dovevano parlare con il server centrale. Se il server era irraggiungibile, o cadeva, eri praticamente bloccato: senza di lui non avevi accesso alla storia, non potevi fare molto. Tutto dipendeva da quel singolo punto centrale, che era anche un singolo punto di fragilità.
Git ha ribaltato completamente questo modello, ed è qui la sua idea rivoluzionaria: quando prendi un progetto Git, non ne ricevi una fetta, ma una copia completa di tutto. Tutta la storia, tutte le istantanee, tutti i commit, tutti i rami, dall'inizio del progetto fino a oggi: tutto quanto, sul tuo computer. Non hai una finestra parziale su un archivio lontano, hai l'intero archivio in mano, una copia integrale e autosufficiente. Ogni sviluppatore, sul proprio computer, ha una copia piena e completa della storia intera del progetto. Questo è ciò che significa distribuito: la storia non vive in un solo posto, ma è replicata per intero in ogni copia.
Le conseguenze sono profonde e liberatorie. Siccome hai l'intera storia sul tuo computer, puoi fare quasi tutto senza collegarti a nessun server: guardare la storia, creare rami, fare fusioni, scattare istantanee, spostarti tra le versioni, tutto in locale, alla velocità del tuo computer, anche senza rete, su un treno o in aereo. Non dipendi da un server per il lavoro quotidiano. E non c'è più un singolo punto di fragilità: se un archivio andasse perso, ogni copia completa contiene l'intera storia e può ricostruire tutto. La storia è al sicuro proprio perché è replicata ovunque.
Ma allora, se ognuno ha la sua copia completa e lavora in autonomia, come fanno le persone a collaborare e a mettere insieme il lavoro? Qui entra il concetto di remoto. Un remoto, in Git, è semplicemente un'altra copia del progetto, che sta altrove, con cui la tua copia può sincronizzarsi. Non è qualcosa di speciale o superiore: è solo un'altra copia come la tua, magari su un altro computer o su un server condiviso, che fa da punto di incontro. Tu e i tuoi colleghi tenete le vostre copie sincronizzate con questa copia comune, e così scambiate il lavoro. Il remoto è un luogo di scambio, non un padrone.
Vediamo come avviene questo scambio, perché è semplice una volta capito il modello. Ci sono due movimenti fondamentali. Da una parte, mandare il tuo lavoro alla copia remota: prendi i commit nuovi che hai fatto in locale e li spingi verso il remoto, così che gli altri possano riceverli. Dall'altra, ricevere il lavoro degli altri: prendi dalla copia remota i commit nuovi che gli altri hanno mandato, e li porti nella tua copia locale. Spingere e ricevere: due direzioni di sincronizzazione tra la tua copia e quella comune. È come due persone che aggiornano a vicenda una cartella condivisa, ciascuno depositando il proprio lavoro e prelevando quello altrui.
Una precisazione utile su come conviene ricevere il lavoro altrui. È saggio farlo in due tempi: prima scaricare i nuovi commit degli altri senza ancora mescolarli col tuo, così puoi guardarli con calma; e solo dopo, deliberatamente, unirli al tuo lavoro. Molti fanno tutto in un colpo, scaricare e unire insieme, ed è comodo, ma separare i due momenti dà più controllo e meno sorprese. È la stessa deliberatezza della sala d'attesa: guardare prima di agire.
Voglio chiudere sfatando un equivoco comune. Le grandi piattaforme dove si ospitano i progetti non sono Git: sono servizi costruiti attorno a Git. Offrono una copia remota comoda e sempre disponibile dove tutti si sincronizzano, e ci aggiungono sopra funzioni utili per collaborare, discutere, rivedere il codice. Ma Git, in sé, non ha bisogno di nessuna di queste piattaforme: funziona benissimo anche con una semplice copia remota su un tuo server. Le piattaforme sono comode, ma sono un di più costruito sopra Git, non Git stesso. Distinguere le due cose ti rende più libero: puoi ospitare i tuoi progetti dove vuoi, perché il cuore, Git, è tuo e completo.
Per oggi ci fermiamo qui. Git è distribuito: a differenza dei vecchi sistemi centralizzati, ogni copia di un progetto è una copia completa di tutta la storia, non una fetta parziale. Questo ti permette di lavorare in autonomia, senza dipendere da un server, e mette la storia al sicuro replicandola ovunque. Per collaborare, si usano i remoti, che sono solo altre copie con cui sincronizzarsi, spingendo il proprio lavoro e ricevendo quello altrui. Le grandi piattaforme sono servizi costruiti attorno a Git, comodi ma non necessari: il cuore resta tuo e completo. Nella prossima e ultima puntata tiriamo le somme. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.