Git, oggi conosciuto come uno degli strumenti di controllo versione più utilizzati al mondo, è nato con un obiettivo iniziale ben preciso. La creazione di Git non fu motivata dal bisogno di costruire un sistema di versionamento, ma da una necessità ben più semplice: la gestione e il tracciamento delle modifiche ai file in modo più efficiente, utilizzando un sistema che potesse permettere di fare snapshot dei contenuti e di mostrare le differenze tra di essi, per consentire discussioni più chiare sui cambiamenti apportati sul codice di programmazione. Questo approccio, nato in ambito open source, ha gettato le basi per quello che sarebbe diventato il sistema di controllo versione distribuito più popolare al mondo.
La Nascita di Git per mano di Linus Torvalds
Linus Torvalds, creatore del kernel Linux, è anche la mente dietro a Git. L’informatico finlandese ideò Git nel 2005 come risposta alla necessità di gestire il codice sorgente del kernel Linux.
La sua creazione non era destinata a essere un sistema di controllo versione completo e sofisticato come quello che conosciamo oggi. Inizialmente, Git era uno strumento molto semplice, nato per gestire principalmente patch e tarball, gruppi di file che venivano condivisi in forma di pacchetti.
La struttura interna di Git, costruita su liste concatenate di alberi di file, con uno storage a oggetti (content-addressable storage), è rimasta invariata sin dal primo commit, costituendo la base su cui è stato costruito il sistema.
L’origine di Git: necessità e pragmatismo
La creazione di Git fu motivata da una crisi: la comunità Linux perse l’accesso a BitKeeper (sistema di controllo versione distribuito che è stato ampiamente utilizzato nei primi anni 2000) a causa di controversie legate al reverse engineering e alle restrizioni di licenza.
Torvalds, insoddisfatto degli strumenti esistenti come CVS e SVN, decise di sviluppare un sistema che rispondesse alle sue esigenze pratiche. In soli dieci giorni, scrisse la prima versione funzionante di Git. Anche se il processo creativo era iniziato mesi prima, con un’intensa riflessione su ciò che funzionava e su come migliorare rispetto agli strumenti disponibili.
“Farò qualcosa che funziona per me e non mi preoccuperò degli altri“, racconta di aver pensato Torvalds ai tempi. Questo atteggiamento iniziale si riflette nella prima versione di Git, considerata grezza e difficile da usare. Nonostante ciò, la sua superiorità tecnica rispetto ai sistemi esistenti era evidente fin dall’inizio.
Il primo commit di Git: un sistema per il tracciamento dei contenuti
Nello sviluppo software e nei sistemi di controllo versione, un “commit” è l’operazione con cui ciascun sviluppatore salva le modifiche apportate al codice o ai file all’interno di un repository. È un’azione fondamentale nei sistemi di controllo versione come Git, che consente di registrare e tracciare i cambiamenti effettuati su uno o più file.
Il primo commit di Git del 2005, firmato Linus Torvalds, introduceva sette strumenti standalone molto basilari, non comandi come quelli che oggi conosciamo. Questi strumenti erano utili per creare una sorta di “istantanea” del contenuto di una directory, memorizzandola in un database come oggetto, e per creare un “cambiamento” (chiamato appunto commit) che associava una nuova istantanea a una versione precedente.
Appositi comandi aggiuntivi erano utilizzati per leggere e visualizzare il contenuto degli oggetti salvati nel database, consentendo la visualizzazione delle differenze tra la cache e la directory di lavoro.
Principi fondamentali e innovazioni tecniche
Git si distingue per alcune scelte progettuali fondamentali che ne hanno garantito il successo:
- Design distribuito: A differenza dei sistemi centralizzati come CVS, Git fu progettato per essere completamente distribuito. Ogni sviluppatore ha una copia completa del repository, rendendo il sistema più robusto e flessibile.
- Performance: Torvalds puntava a garantire prestazioni elevate. L’applicazione delle patch doveva essere quasi istantanea, anche per serie complesse di centinaia di modifiche. Questo era essenziale per agevolare il lavoro degli sviluppatori.
- Integrità dei dati: L’uso degli hash SHA-1 per identificare gli oggetti nel repository non mirava alla sicurezza crittografica ma alla rilevazione della corruzione dei dati. Questa scelta ha garantito una stabilità senza precedenti nel controllo delle versioni.
Torvalds paragonò la filosofia progettuale di Git a quella di Unix: semplicità alla base con complessità nei dettagli. I concetti fondamentali di Git, come gli oggetti immutabili e la struttura basata sugli hash, sono semplici da comprendere, ma l’implementazione ha richiesto attenzioni non convenzionali dal punto di vista tecnico.
L’evoluzione di Git
Nel tempo, Git ha fatto evolvere la sua struttura, con l’introduzione di comandi di base come git commit
, git diff
e git log
, che hanno semplificato enormemente l’utilizzo del sistema. Questi comandi sono stati inizialmente scritti come script di shell e Perl per rendere l’interfaccia utente più semplice da usare, ma con il passare degli anni, sono stati riscritti in linguaggio C per garantirne la portabilità e l’efficienza.
L’adozione di Git è aumentata quando si è resa evidente la sua versatilità anche in ambiti in cui la gestione del codice non era la necessità principale. Ad esempio, tante realtà si sono avvalse di Git per tracciare i loro contenuti distribuiti, di qualunque tipo, piuttosto che per gestire codice sorgente. In questi frangenti, Git si è rivelato estremamente efficiente nel trasferire solo i file modificati, risparmiando banda e spazio di archiviazione.
L’ascesa e la nascita di GitHub
L’evoluzione di Git è stata accelerata da molteplici contributi esterni, che hanno avuto il merito di semplificare l’utilizzo dello strumento e renderlo più accessibile per una comunità di sviluppatori sempre più vasta.
Nel 2008, poi, nacque GitHub, una piattaforma che sfruttava Git come base per offrire uno strumento di collaborazione per lo sviluppo software. GitHub ha reso Git ancora più popolare, grazie alla sua interfaccia grafica user-friendly e alla possibilità di lavorare facilmente su progetti condivisi.
GitHub ha cambiato il modo in cui gli sviluppatori collaborano, facilitando il lavoro su progetti open source e non solo, e rendendo Git lo standard de facto per il controllo versione. Da giugno 2018 GitHub è di proprietà di Microsoft.
Un aspetto curioso della storia di Git riguarda la fusione delle modifiche, che in Git può avvenire attraverso una strategia chiamata octopus merge. Essa consente di unire più branch simultaneamente e, vista la portata dell’innovazione, il polpo è diventato proprio il simbolo di GitHub. Il polpo è anche un po’ gatto (non per nulla il logo di GitHub si chiama octocat): il felino rappresenta la flessibilità e l’abilità di Git nel gestire diverse situazioni, proprio come un gatto che è noto per essere agile e in grado di adattarsi a vari contesti. La fusione di questi due simboli, quindi, gioca sull’idea di versatilità, potenza e capacità di gestire molteplici modifiche, un tratto distintivo di Git.
Credit immagine in apertura: iStock.com – Jay Yuno