Git nasce nel 2005 per risolvere un problema concreto nello sviluppo del kernel Linux: gestire modifiche distribuite fra moltissime persone con velocità e affidabilità. Linus Torvalds si mette a scriverlo dopo la fine dell'accordo che permetteva alla community di usare gratuitamente BitKeeper.

È una storia che mi piace perché mette insieme necessità tecnica, libertà degli strumenti e collaborazione. E perché il risultato non è rimasto dentro Linux: Git è diventato la base del modo in cui quasi tutti lavorano sul software.

Che cosa fa Git

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

«Distribuito» significa che un clone normale contiene dati e storia del progetto, non solo i file attuali. Molte operazioni le fai in locale, senza dipendere da un server sempre raggiungibile — che nel 2005 era un problema molto più sentito di oggi.

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

Prima di Git: il problema della collaborazione

Con la crescita del kernel crescevano modifiche da valutare, contributori e responsabilità di integrazione. Scambiare patch e tenere una storia coerente richiedeva strumenti all'altezza.

Dal 2002 la community usava BitKeeper, sistema proprietario con modello distribuito. Nel 2005 il rapporto si interrompe e la disponibilità gratuita finisce. La storia di Git nel manuale Pro Git riassume il passaggio.

C'è di mezzo anche la controversia sul lavoro di Andrew Tridgell riguardo all'interoperabilità con BitKeeper. Ma il punto che genera Git è un altro: dipendere da uno strumento la cui disponibilità poteva cambiare indipendentemente dalle esigenze del progetto.

Che cosa cercava Torvalds

Voleva tenere i vantaggi del lavoro distribuito migliorando il rapporto fra prestazioni e gestione di un progetto enorme. Velocità, integrità dei dati e capacità di reggere molti percorsi di sviluppo erano i requisiti.

Le sue critiche a CVS e Subversion rendono la storia divertente, ma quello che conta tecnicamente è la distanza fra il workflow che voleva e quello che gli strumenti offrivano.

Git nasce quindi con una direzione precisa: rispondere alle esigenze di integrazione del kernel, senza restare legato al modello che Torvalds stava abbandonando.

Branch e merge: lavorare in parallelo

Un branch è una linea di sviluppo. In Git non è una copia separata di tutti i file: è un riferimento che segue una sequenza di commit — ed è il motivo per cui crearne uno costa praticamente nulla.

Puoi usarlo per sperimentare una funzione senza toccare il percorso principale. Quando è pronta, un merge integra le storie; se le modifiche non si conciliano da sole, risolvi i conflitti a mano.

Non è caricare un file nuovo sopra quello vecchio cancellando la storia. E merge e pubblicazione sul server non sono la stessa operazione: puoi integrare in locale e condividere dopo.

È proprio questa separazione a rendere il modello adattabile a team e progetti molto diversi.

Dalla prima versione a Junio Hamano

Lo sviluppo iniziale fu rapidissimo. Il repository conserva il primo commit, e83c516, ancora leggibile: il manuale Git lo propone come riferimento per capire la struttura originaria.

Nel corso del 2005 Torvalds affida la manutenzione a Junio C. Hamano, già fra i contributori più attivi. Ci insisto perché la storia di Git non finisce con la sua invenzione.

Dare continuità a un progetto, renderlo usabile e farlo evolvere è un lavoro diverso dallo slancio iniziale — spesso più difficile. Il ruolo di Hamano e della community è parte del risultato, non una nota sotto il nome di Torvalds.

Il nome, e l'ironia del suo creatore

Il nome riflette il tono di Torvalds: «git» nello slang britannico non è un complimento, e lui ci ha giocato sopra attribuendogli significati diversi a seconda dell'umore.

L'aneddoto mi piace perché rende riconoscibile la persona dietro il progetto. Ma la brevità del comando ha anche una ragione pratica, per uno strumento nato per essere usato dal terminale mille volte al giorno.

Git non è GitHub

Intorno 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 resta distinto dalla piattaforma. Puoi usare Git senza GitHub e scegliere altri modi di pubblicare e collaborare — una cosa che a molti non è mai stata detta.

La distinzione aiuta a capire la portata del progetto: Git ha creato un'infrastruttura comune sulla quale altri hanno costruito servizi e modelli di business.

Una necessità precisa genera uno strumento duraturo

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

E il suo percorso mostra quanto valga la manutenzione: un'intuizione diventa uno strumento affidabile solo quando altre persone possono capirla, usarla e migliorarla nel tempo. È uno dei motivi per cui trovo questa storia così rappresentativa.