Git nasce nel 2005 per risolvere un problema concreto dello sviluppo del kernel Linux: gestire modifiche distribuite tra molte persone con velocità e affidabilità. Linus Torvalds ne avvia la realizzazione dopo la fine dell'accordo che consentiva alla community di utilizzare gratuitamente BitKeeper.

È una storia che trovo affascinante perché collega necessità tecnica, libertà degli strumenti e collaborazione. Il risultato non rimane confinato a Linux: Git diventa la base di molti modi di lavorare sul software.

Che cosa fa Git

Git è un sistema di controllo delle versioni distribuito. Registra la storia delle modifiche ai file e permette di lavorare su linee di sviluppo differenti, confrontarle e integrarle.

“Distribuito” significa che un normale clone del repository contiene dati e storia del progetto, non soltanto una copia dei file correnti. Molte operazioni possono quindi essere effettuate localmente, senza dipendere da un server centrale sempre raggiungibile.

Questo non impedisce a un gruppo di adottare un repository remoto come riferimento organizzativo. La distribuzione riguarda il modello tecnico; il workflow del team è una scelta ulteriore.

Prima di Git: il problema della collaborazione su Linux

Con la crescita del kernel aumentavano anche modifiche da valutare, contributori e responsabilità di integrazione. Scambiare patch e mantenere una storia coerente richiedeva strumenti adeguati alla scala del progetto.

Nel 2002 la community iniziò a usare BitKeeper, un sistema proprietario che offriva un modello distribuito. Nel 2005 la relazione si interruppe e la disponibilità gratuita venne meno. La storia di Git pubblicata nel manuale Pro Git riassume questo passaggio.

Nel video richiamo la controversia legata al lavoro di Andrew Tridgell sull'interoperabilità con BitKeeper. Il punto essenziale per la nascita di Git è la dipendenza da uno strumento la cui disponibilità poteva cambiare, indipendentemente dalle esigenze del kernel.

Le caratteristiche cercate da Torvalds

Torvalds voleva conservare i vantaggi del lavoro distribuito, migliorando il rapporto tra prestazioni e gestione di un progetto molto grande. Velocità, integrità dei dati e capacità di sostenere molti percorsi di sviluppo erano requisiti centrali.

Nel video racconto anche la sua critica a strumenti come CVS e Subversion. La contrapposizione rende vivace la storia, ma ciò che conta tecnicamente è la distanza tra il workflow desiderato e quello offerto dagli strumenti presi in considerazione.

Git nasce quindi con una direzione precisa: rispondere alle esigenze di integrazione del kernel, senza essere vincolato al modello che Torvalds aveva deciso di abbandonare.

Branch e merge: lavorare in parallelo

Un branch rappresenta una linea di sviluppo. In Git non è necessariamente una copia completa e separata di tutti i file: è un riferimento che permette di seguire una sequenza di commit.

Posso usare un branch per sperimentare una funzione senza inserirla subito nel percorso principale. Quando il lavoro è pronto, un merge può integrare le storie. Se le modifiche non sono conciliabili automaticamente, bisogna risolvere i conflitti.

Questo non equivale a caricare un file nuovo sopra quello vecchio cancellando la storia. Né merge e pubblicazione sul server sono la stessa operazione: il lavoro può essere integrato localmente e condiviso in un secondo momento.

È proprio questa separazione che rende il modello flessibile per team e progetti differenti.

Dalla prima versione a Junio Hamano

Lo sviluppo iniziale fu molto rapido. Il repository conserva il primo commit, e83c516, come punto di partenza leggibile ancora oggi: il manuale Git lo propone anche come riferimento per capire la struttura originaria del progetto.

Nel corso del 2005 Torvalds affidò la manutenzione a Junio C. Hamano, già tra i contributori più attivi. Nel video insisto su questo passaggio perché la storia di Git non termina con la sua invenzione.

Dare continuità al progetto, renderlo più usabile e farlo evolvere richiede un lavoro diverso dallo slancio iniziale. Il ruolo di Hamano e della community è quindi parte essenziale del risultato, non una nota marginale dietro il nome di Torvalds.

Il nome e l'ironia del suo creatore

Anche il nome riflette il tono provocatorio di Torvalds. Nel video ricordo il significato poco lusinghiero di “git” nello slang britannico e il gioco di attribuire al termine interpretazioni differenti.

L'aneddoto mi piace perché rende riconoscibile la persona dietro il progetto. La brevità del comando, però, è anche un elemento pratico per uno strumento nato con un uso importante da terminale.

Git non è GitHub

Attorno a Git sono cresciuti servizi come GitHub, GitLab e Bitbucket. Ospitano repository e aggiungono strumenti per discutere modifiche, organizzare il lavoro e automatizzare attività.

Il sistema di versionamento rimane distinto dalla piattaforma. Si può utilizzare Git senza GitHub e scegliere modalità diverse di pubblicazione o collaborazione.

Questa distinzione aiuta a capire la portata del progetto: Git ha reso possibile un'infrastruttura comune sulla quale altri hanno costruito servizi e modelli di attività differenti.

Una necessità precisa può generare uno strumento duraturo

La parte che mi colpisce di più è il rapporto tra problema e soluzione. Git non nasce da un'idea astratta di successo, ma dalla necessità di continuare a lavorare su un progetto importante con strumenti adeguati.

Il suo percorso mostra anche il valore della manutenzione: un'intuizione diventa uno strumento affidabile quando altre persone possono comprenderla, usarla e migliorarla nel tempo. È uno dei motivi per cui considero questa storia così rappresentativa del mondo del software.