Ciao, e benvenuto nell'ottava puntata della quattordicesima stagione. Finora abbiamo costruito la storia in avanti: commit dopo commit, istantanea dopo istantanea. Oggi affrontiamo un potere più audace e delicato, uno di quelli che affascina e insieme spaventa: riscrivere la storia. La capacità di tornare indietro e riordinare, ripulire, rimodellare i commit già fatti. È uno degli aspetti più potenti di Git, ma anche uno di quelli che, se usato male, può causare guai. Quindi lo affrontiamo con rispetto, capendo prima il come e poi il quando.
Partiamo da una domanda che forse ti sei fatto: se i commit sono immutabili, come dicevamo, come si fa a riscrivere la storia? Non è una contraddizione? La risposta scioglie l'apparente paradosso, ed è la chiave di tutto. Riscrivere la storia, in Git, non significa modificare i commit esistenti, che restano immutabili. Significa creare nuovi commit che sostituiscono i vecchi, e poi spostare le etichette dei rami per puntare ai nuovi invece che ai vecchi. I commit originali, tecnicamente, restano lì, ma le etichette non li indicano più, e la storia che vedi è quella nuova. Riscrivere è costruire una versione nuova e spostare l'etichetta su di essa.
Vediamo a cosa serve, concretamente, questo potere, perché ha usi molto pratici e utili. Immagina di aver lavorato in modo disordinato: hai fatto tanti piccoli commit confusi, con messaggi frettolosi, dei ritocchi qua e là, dei ripensamenti. La storia che ne risulta è un guazzabuglio difficile da leggere. Riscrivere la storia ti permette di ripulire tutto questo prima di condividerlo: puoi unire più commit sparsi in uno solo, ben fatto; puoi riordinare i commit in una sequenza logica; puoi correggere un messaggio scritto male; puoi eliminare un commit inutile. In sostanza, puoi trasformare una storia caotica in un racconto pulito e ordinato.
Voglio soffermarmi su perché questo sia prezioso, perché riprende un tema fondamentale del podcast. Ricordi, dalla prima stagione, l'importanza di scrivere pensando a chi verrà dopo, di rendere il proprio lavoro leggibile per gli altri? La storia di un progetto è essa stessa una forma di comunicazione: raccontata bene, con commit ordinati e messaggi chiari, aiuta chi la leggerà in futuro a capire come e perché il progetto si è evoluto. Riscrivere la storia per ripulirla è un atto di cura verso i futuri lettori, esattamente come scrivere codice leggibile. Non è vanità: è rendere comprensibile il percorso a chi dovrà ricostruirlo. Una storia pulita è un dono.
Ma ora arriviamo alla parte delicata, e devo essere molto chiaro, perché qui si annidano i guai. Riscrivere la storia è sicuro e utile finché quella storia è solo tua, ancora sul tuo computer, non condivisa con nessuno. Puoi rimaneggiarla quanto vuoi, perché nessun altro dipende da essa. Ma diventa pericoloso, anzi dannoso, quando riscrivi una storia che hai già condiviso con altri, su cui altri stanno già lavorando. Perché se tu cambi la storia che altri hanno, e poi la imponi, mandi in confusione tutti quelli che avevano la versione precedente: il loro lavoro si basava su commit che, per te, non esistono più. Crei un disallineamento doloroso, difficile da districare.
Da qui nasce una delle regole d'oro più importanti di tutto Git, che voglio consegnarti con solennità: non riscrivere la storia che hai già condiviso con altri. La storia ancora privata, tutta tua, riscrivila pure liberamente, è un tuo diritto e uno strumento prezioso. Ma la storia pubblica, quella già uscita e su cui altri poggiano il loro lavoro, va lasciata stare, trattata come qualcosa di ormai scolpito. Riprendo un tema dell'undicesima stagione, quella sui browser: quando qualcosa è condiviso e altri vi si appoggiano, cambiarlo unilateralmente rompe la fiducia e il lavoro di tutti. La storia condivisa è un bene comune, e non si stravolge di nascosto.
C'è una versione più leggera e quotidiana di questo potere: la correzione dell'ultimo commit. Capita spesso di scattare un'istantanea e accorgersi subito dopo di aver dimenticato qualcosa, o di aver scritto male il messaggio. Git ti permette di aggiustare al volo l'ultimo commit, sostituendolo con una versione corretta. Finché è ancora solo tuo e non condiviso, è comodissimo e innocuo: lo stesso principio, creare un nuovo commit al posto del vecchio, applicato solo all'ultimo passo. Un piccolo lusso quotidiano per tenere pulita la propria storia.
Voglio chiudere con l'atteggiamento giusto verso questo potere. Riscrivere la storia è magnifico per la cura e la pulizia, da usare con generosità sul lavoro privato e con grande prudenza su quello condiviso. Non temerlo al punto da non usarlo mai, ma non abusarne al punto da stravolgere il lavoro altrui. La saggezza sta nell'equilibrio e nella consapevolezza di cosa stai facendo e di chi ne sarà toccato. Con il modello in testa, sai esattamente cosa succede quando riscrivi: crei nuovi commit e sposti etichette. E questo ti permette di farlo con sicurezza, non con paura.
Per oggi ci fermiamo qui. Riscrivere la storia non significa modificare i commit immutabili, ma creare nuovi commit e spostare le etichette su di essi. Serve a ripulire una storia disordinata, unendo, riordinando e correggendo, un atto di cura verso i futuri lettori, come il codice leggibile. Ma vale una regola d'oro: riscrivi liberamente la storia ancora privata, mai quella già condivisa su cui altri poggiano, perché stravolgerla rompe il loro lavoro e la fiducia. È un potere magnifico, da usare con equilibrio e consapevolezza. Nella prossima puntata scopriamo la natura distribuita di Git: il locale e il remoto. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.