Git 2.56 è disponibile da oggi, 28 settembre 2026. La nuova versione del sistema distribuito di controllo del codice introduce nuovi strumenti per gestire i branch, miglioramenti nella risoluzione dei conflitti, nuove possibilità per l'automazione e numerose ottimizzazioni. Ma è anche una buona occasione per raccontare uno dei programmi liberi che hanno cambiato profondamente il modo nel quale viene costruito il software.
Chi utilizza Git quotidianamente potrebbe considerarlo semplicemente uno strumento attraverso il quale eseguire commit, creare branch, inviare modifiche a un repository e successivamente unirle.
Dietro questi comandi esiste però un'idea molto più importante.
Git conserva la storia di un progetto.
Non soltanto i file così come sono oggi, ma la successione delle modifiche attraverso le quali sono arrivati allo stato attuale.
Possiamo sapere quando una riga è stata modificata, confrontare due momenti differenti, recuperare una versione precedente, sviluppare contemporaneamente soluzioni alternative e successivamente decidere quali integrare.
È una sorta di memoria del software.
Git 2.56 introduce diversi miglioramenti proprio nella gestione quotidiana di questa memoria.
Tra le novità troviamo nuove possibilità per git branch, pensate per rendere più semplice individuare e ripulire branch che non servono più.
Chi lavora su progetti complessi conosce bene il problema.
Ogni nuova funzione, correzione o esperimento può nascere in un branch differente. Una volta che il lavoro viene integrato, alcuni di questi branch rimangono nel repository anche quando non hanno più una funzione reale.
Con il tempo possono accumularsi decine o centinaia di riferimenti che rendono più difficile comprendere lo stato del progetto.
Git 2.56 introduce strumenti che aiutano a distinguere meglio ciò che è ancora attivo da ciò che può essere eliminato.
Migliora anche un'altra delle situazioni che più facilmente spaventano chi comincia a utilizzare Git: i conflitti.
Un conflitto si verifica quando due modifiche non possono essere integrate automaticamente.
Immaginiamo due persone che modificano contemporaneamente la stessa parte di un documento. Git può conservare entrambe le storie, ma a un certo punto qualcuno deve decidere quale delle due modifiche mantenere oppure come combinarle.
Non è necessariamente un errore.
È la conseguenza naturale della collaborazione.
Git 2.56 aggiunge nuove possibilità per rendere più chiaro e controllabile questo processo, migliorando gli strumenti attraverso i quali vengono gestite le risoluzioni dei conflitti.
Ed è proprio qui che possiamo comprendere una delle caratteristiche fondamentali di Git.
Non impedisce alle persone di lavorare contemporaneamente sullo stesso progetto. È progettato affinché possano farlo.
Ogni sviluppatore può possedere sul proprio computer una copia completa del repository e della sua storia.
Non è necessario essere continuamente collegati a un server centrale per creare commit, consultare versioni precedenti o costruire nuovi branch.
La sincronizzazione può avvenire successivamente.
È il significato della parola distribuito nella definizione Distributed Version Control System.
Questa architettura ha anche una conseguenza interessante dal punto di vista dell'autonomia.
Git non coincide con GitHub.
E non coincide nemmeno con GitLab, Codeberg o qualsiasi altra piattaforma attraverso la quale possiamo pubblicare un repository.
Questi servizi utilizzano Git, aggiungendo interfacce web, gestione degli utenti, issue tracker, pull request, CI/CD e molte altre funzioni.
Ma Git può funzionare senza di loro.
Possiamo creare un repository sul nostro computer.
Possiamo conservarlo su un server controllato direttamente da noi.
Possiamo trasferirlo attraverso SSH.
Possiamo utilizzare un servizio pubblico oppure costruire una nostra infrastruttura.
È una distinzione che diventa particolarmente importante mentre una parte crescente dello sviluppo software tende a concentrarsi all'interno di poche grandi piattaforme.
Un progetto può utilizzare una piattaforma commerciale per comodità senza necessariamente consegnarle il formato fondamentale nel quale viene conservata la propria storia.
Il repository Git rimane replicabile.
Può essere clonato.
Può essere spostato.
E ogni clone contiene normalmente la storia necessaria per continuare a lavorare.
Naturalmente nessuna architettura tecnica elimina completamente il rischio di dipendenza.
Issue, discussioni, sistemi di automazione e altre informazioni possono essere legati a una particolare piattaforma.
Ma il cuore dello sviluppo — codice e cronologia delle modifiche — rimane costruito attraverso un protocollo e uno strumento libero.
La storia di Git rende tutto questo ancora più interessante.
Il programma nacque nel 2005, quando lo sviluppo del kernel Linux perse la possibilità di continuare a utilizzare BitKeeper, il sistema proprietario di controllo delle versioni adottato in quel periodo.
Linus Torvalds iniziò allora a sviluppare un nuovo strumento adatto alle particolari esigenze del kernel: velocità, distribuzione del lavoro, integrità della cronologia e capacità di gestire un numero enorme di modifiche.
Git nacque quindi anche da un problema di dipendenza tecnologica.
Uno dei più importanti progetti di Software Libero del mondo dipendeva per una parte fondamentale del proprio processo di sviluppo da uno strumento che non controllava completamente.
La risposta fu costruirne uno libero.
Da quel problema nacque qualcosa che successivamente avrebbe superato enormemente il proprio contesto originale.
Git non viene oggi utilizzato soltanto per Linux.
È diventato uno degli strumenti dominanti per lo sviluppo software in praticamente ogni settore.
Applicazioni web, sistemi operativi, firmware, documentazione, configurazioni e perfino libri possono essere gestiti attraverso repository Git.
E non è necessario essere programmatori per comprenderne il principio.
Pensiamo a un documento importante.
Lo modifichiamo oggi, domani e la settimana successiva.
A un certo punto scopriamo che tre giorni fa abbiamo eliminato un paragrafo che invece ci serviva.
Il metodo tradizionale potrebbe essere creare file come:
documento.doc
documento_nuovo.doc
documento_finale.doc
documento_finale2.doc
documento_finale_veramente_definitivo.doc
Git affronta lo stesso problema in maniera completamente differente.
Il documento può mantenere lo stesso nome mentre è la sua storia a essere conservata separatamente.
Ogni stato significativo può essere registrato e accompagnato da una spiegazione.
Possiamo quindi tornare indietro senza dover creare manualmente decine di copie.
Quando più persone lavorano insieme, il vantaggio diventa ancora maggiore.
Ognuna può sviluppare una modifica senza distruggere il lavoro degli altri e successivamente le differenti linee di sviluppo possono essere confrontate e integrate.
È una tecnologia nata per il codice, ma il principio che esprime è molto più generale:
la collaborazione funziona meglio quando le modifiche sono tracciabili e reversibili.
C'è inoltre una caratteristica di Git che merita particolare attenzione.
Ogni commit viene identificato attraverso un hash derivato anche dal proprio contenuto e dalla storia precedente.
La cronologia forma quindi una struttura nella quale le modifiche sono collegate tra loro.
Non significa che Git sia automaticamente un sistema di sicurezza o che renda impossibile qualsiasi manipolazione.
Significa però che l'integrità della storia è parte fondamentale della sua architettura.
Ed è particolarmente importante quando migliaia di persone collaborano su uno stesso progetto.
Git 2.56 continua ad affinare questo sistema dopo più di vent'anni.
Nuovi comandi, miglioramenti nella gestione dei branch, strumenti per i conflitti e ottimizzazioni possono sembrare modifiche relativamente piccole rispetto all'importanza complessiva del programma.
Ma è proprio così che maturano le infrastrutture.
Non vengono necessariamente reinventate ogni anno.
Vengono corrette, semplificate e adattate ai nuovi modi nei quali vengono utilizzate.
Git è oggi talmente diffuso da essere quasi invisibile.
Quando scarichiamo il codice di un progetto da un repository, raramente pensiamo all'infrastruttura che permette a quella storia di esistere.
Eppure dietro molti dei programmi liberi dei quali parliamo quotidianamente c'è proprio Git.
Il kernel Linux viene sviluppato con Git.
Migliaia di progetti GNU/Linux vengono sviluppati con Git.
Una quantità enorme del Software Libero mondiale viene costruita attraverso Git.
Ed è forse questa la caratteristica più interessante della nuova versione.
Git è Software Libero che permette di costruire altro Software Libero.
Non decide dove dobbiamo pubblicare il nostro codice.
Non richiede necessariamente un account.
Non obbliga a utilizzare un particolare servizio cloud.
Ci offre invece un formato e degli strumenti attraverso i quali possiamo conservare la storia del nostro lavoro e condividerla con altri.
Git 2.56 migliora ancora questi strumenti.
Ma il principio fondamentale rimane quello nato più di vent'anni fa da una necessità molto concreta: la storia del codice di un progetto libero non dovrebbe dipendere da uno strumento che quel progetto non è libero di controllare.
È una lezione che, nel 2026, rimane sorprendentemente attuale.