Introduzione
Git è uno degli strumenti più noti e utilizzati dagli sviluppatori software, e a buona ragione: rappresenta un aiuto davvero importante per poter gestire lo sviluppo del codice in maniera distribuita e collaborativa.
Vedremo nel corso della serie diversi aspetti pratici legati a Git, ma in questo primo articolo affronteremo alcuni aspetti “collaterali” che però hanno una loro importanza per capire meglio certe scelte e certe caratteristiche del prodotto. In particolare ci concentreremo sulla storia di Git, presentando alcuni fatti probabilmente sconosciuti a gran parte di coloro che usano Git, magari proprio su base quotidiana.
Il nome Git
Anzitutto, cerchiamo di capire cosa significa “Git”. E il miglior modo di iniziare è citare le parole del padre di Git, Linus Torvalds.
“D: Perché è stato scelto il nome ‘Git’?
R: Sono dannatamente egocentrico, e chiamo tutti i miei progetti in modo che rimandino direttamente a me: prima ‘Linux’ e adesso ‘Git’.”
La battuta sta nel fatto che git, nello slang britannico, identifica una persona polemica, che vuole sempre avere ragione. Come spiegato nelle FAQ relative al software, va anche detto che il nome “Git” può avere svariate altre accezioni, “a seconda dell’umore…”. Anzitutto, si tratta di una combinazione di tre lettere, facilmente pronunciabile e non usata da comandi UNIX. Poi, c’è il fatto che la pronuncia può assomigliare a quella di “get”. Può essere la sigla di Global Information Tracker. ma anche di altre combinazioni di parole meno simpatiche, nel caso non funzioni… e così via [1].
Chi conosce la figura di Linus Torvalds, sa che questo è il suo stile: diretto, geniale e spesso irrispettoso; dati i risultati ottenuti, direi però che possiamo perdonargli tutto… o quasi.
All’inizio era BitKeeper
La prima versione di Git vede la luce nell’aprile del 2005. Linus Torvalds, come tutti sanno, è il papà del kernel Linux, progetto del quale ricopre ancora il ruolo di “dittatore benevolente”. Questo progetto consta di qualche milione di linee di codice; avendo a che fare con una simile mole di dati, tutti potranno capire quanto possa essere importante avere un sistema di versioning preciso ed efficiente.
Il primo DVCS
Prima dell’avvento di Git quel ruolo era occupato da BitKeeper [2] un Distributed Version Control System (DVCS) proprietario, sviluppato da BitMover Inc.; a capo della società c’era Larry McVoy, il creatore di quello che ad oggi possiamo definire il primo DVCS della storia.
Leggenda narra che nel 1998 fu lo stesso McVoy ad offrire il suo prodotto agli sviluppatori del kernel Linux, scrivendo un post sulla Linux Kernel Mailing List dove diceva di avere “una soluzione ai crescenti dolori” di cui il progetto del pinguino soffriva.
In quel periodo Linus si occupava di vagliare e integrare manualmente tutte le modifiche che venivano proposte per il kernel, modifiche che gli venivano recapitate via mail in forma di patch.
Ciò che era un mero side-project di uno studente universitario di origini finlandesi, era oramai diventato un prodotto su cui contavano sia privati che aziende, e l’aspettativa in termini di qualità e quantità di funzionalità continuava a crescere di giorno in giorno.
McVoy, in quel post, invitava a riflettere su questo punto: Linus è uno solo, e non possiamo averne più d’uno. Quello che si può fare per migliorare la situazione è cercare di distribuire il lavoro di integrazione su più persone, offrendo uno strumento sufficientemente potente ed efficace affinché non si commettano errori e non vada sprecato il lavoro di nessuno.
Nonostante l’offerta fosse allettante, e il prodotto fosse sufficientemente promettente e maturo per svolgere il compito per cui lo si stava proponendo, l’offerta non fu accettata prima del 2002, e non senza voci contrarie; non ci si stupirà quindi se la collaborazione durò solo 3 anni.
Problemi di licenza e reverse-engineering
Nel 2005, infatti, i rapporti si incrinarono irrimediabilmente. Larry McVoy accusò Andrew Tridgell — Linux contributor e figura di spicco nel mondo FLOSS — di portare avanti un progetto di reverse–engineering del codice di BitKeeper, violando così gli accordi stabiliti. Tridgell, che sostenne di non aver mai accettato di persona alcuna licenza, disse di non aver fatto altro che mettersi in ascolto sul canale di comunicazione di BitKeeper, analizzandone per scopi “etici” il protocollo di comunicazione, come del resto aveva già fatto con Samba.
Questo però non piacque affatto a McVoy; nella licenza di uso gratuito concessa agli sviluppatori del kernel, infatti, c’erano diverse ed esplicite clausole che miravano a proteggerne il più possibile la sua architettura. Oltre a non poterne fare reverse-engineering, cosa piuttosto ovvia per un prodotto commerciale, ad esempio ne era stato vietato l’utilizzo a chi contribuisse allo sviluppo di altri sistemi di versionamento.
Addirittura ne era stato proibito l’uso a chiunque collaborasse con gli Open Source Development Labs (OSDL) [3]; tra questi collaboratori, il più famoso era certo Andrew Morton, il braccio destro di Linus.
Fu così quindi che McVoy decise di revocare per sempre e a tutti la licenza di uso gratuito di BitKeeper: da lì in poi, chiunque avesse voluto utilizzare BitKeeper avrebbe dovuto pagare.
La crisi come occasione
E fu così che, da un giorno all’altro, il più famoso progetto open source della storia si trovò senza un sistema di gestione del codice sorgente.
Nel gruppo di lavoro di Linux, però, ci fu chi non considerò affatto l’avvenimento come una tragedia; anzi, probabilmente gridò alla salvezza. Motivi di disappunto per l’adozione di BitKeeper — in definitiva un prodotto proprietario — erano stati presenti fin dall’inizio e, per molte persone, questa rottura fu senz’altro un evento positivo, una liberazione dalle stringenti regole imposte da McVoy.
Fra chi fu contento di tale rottura, ci furono sicuramente Richard Stallman e Alan Cox, personaggi di spicco del mondo FLOSS. Essi sollevarono delle perplessità fina dalla prima ora, legate soprattutto al fatto di ritenere inappropriato l’uso di software proprietario per lo sviluppo di codice libero; Cox, per esempio, nonostante fosse uno dei maggiori contributori del kernel Linux, non volle usare ne usò mai BitKeeper, ma obbligò di fatto McVoy a realizzare strumenti di interoperabilità con CVS e Subversion in modo che si potesse accedere al codice di Linux utilizzando strumenti open source.
Fu così che, mentre correva l’anno 2005, iniziò la ricerca di un’alternativa.
Addio BitKeeper, benvenuto Git
Abbiamo visto come, a un certo punto, ci si trovò nella condizione di cercare un altro strumento che potesse supportare lo sviluppo del kernel Linux. Le alternative all’epoca non erano certo inesistenti; il mondo open source metteva già a disposizione diversi strumenti di versionamento del codice sorgente. Fra questi c’era Concurrent Versions System (CVS) [4], uno dei più “antichi” sistemi di versionamento.
Sfiducia in CVS e Subversion
Torvalds però non aveva una buona opinione di CVS; quando più avanti decise quali dovessero essere i tre punti focali sui quali fondare lo sviluppo di Git, iniziò infatti da questo:
“Prendere Concurrent Versions System (CVS) come esempio di quello che non va fatto; nel dubbio, fare delle scelte in senso esattamente contrario”.
Come si capisce da questa affermazione, nonostante la sua lunga storia — la prima versione di CVS risale infatti al 1990 — questo strumento non ha mai incontrato il favore di Linus. In un famoso talk del 2007 [5], Linus ricorda come, durante i primi anni di sviluppo del kernel Linux, per scambiarsi codice si usavano semplicemente tarball e patch, definendoli “un sistema di gestione del controllo migliore rispetto a CVS”…
Linus, si sa, non ha peli sulla lingua; quando però parte all’attacco di qualcosa — o di qualcuno — non lo fa — quasi — mai per partito preso. Linus ha infatti usato CVS per anni durante nella sua quotidiana attività lavorativa, ed è stato questo, a suo stesso dire, ad averlo portato ad “odiare” con passione il povero CVS.
Qualcuno starà pensando ora a cosa possa pensare Linus di Subversion [6], all’epoca già con 5 anni di storia alle spalle… be’, non aspettatevi certo giudizi migliori. Subversion, secondo Linus, è stato il “progetto più inutile mai cominciato”, e questo a causa del suo stesso slogan, in cui si definisce un “CVS done right”. “Non c’è modo di fare CVS bene!” è il lapidario giudizio del celebre hacker finlandese.
Workflow distribuito e Monotone
Folklore a parte, questi sistemi non rispondevano a un altro dei requisiti che Linus aveva dettato: il workflow distribuito, che BitKeeper aveva di fatto inventato. L’unico era Monotone [7], uno tra i primi DVCS open source a fare la propria comparsa sul mercato. Va notato che sia Bazaar [8] che Mercurial [9] sono praticamente coscritti di Git, essendo lo sviluppo di entrambi iniziato nella primavera del 2005.
Monotone era ai tempi l’unico a rispettare i vincoli di atomicità dei commit e di workflow desiderati; nonostante questo però, non riuscì mai a ottenere i favori del padre-padrone di Linux. Il problema di Monotone era la sua lentezza; nei suoi esperimenti, Linus impiegò quasi due ore per il caricamento di una sola revisione del kernel Linux. Monotone è scritto in C++, e utilizza un vero e proprio database per indicizzare i dati; Linus, guarda caso, non è mai stato un fan né dell’una né dell’altra scelta tecnologica. Dalle sue stesse parole:
“Se volete un VCS scritto in C++, usate pure Monotone. Davvero. Usa un ‘vero database’. Usa delle ‘buone librerie OO’. Usa delle ‘buone astrazioni C++’. Ma, per essere franchi, a fronte di tutte queste decisioni di design che sembrano tanto attraenti per alcuni esperti di informatica, il risultato finale è un casino orribile e impossibile da manutenere”.
La necessità di un nuovo DVCS
Fu così quindi che venne presa la decisione di creare un DVCS ex novo che rispettasse i canoni di sicurezza, velocità e affidabilità richiesti per lo sviluppo di un progetto come il kernel Linux.
La prima riga di codice di Git fu scritta il 6 aprile del 2005; lo sviluppo proseguì rapidissimamente, tant’è che il 18 aprile era già presente la funzionalità di merge multiplo. Due mesi dopo, il 16 giugno del 2005, il kernel Linux versione 2.6.12 era già gestito tramite Git.
Dopo aver reso lo strumento sufficientemente utilizzabile — da persone però della sua stessa levatura tecnica — il 26 luglio Linus decise di portare il progetto in maintenance, e cioè di cedere lo scettro di “capo mastro” a qualcuno che potesse da lì in poi curarne lo sviluppo.
Questa persona è Junio Hamano [10].
Lo stato attuale
Quando parliamo di Git, parliamo spesso e volentieri di Linus Torvalds; molti però dimenticano che Linus fu “solo” colui che ne ha accesa la miccia; dopo una manciata di settimane passate a scrivere una prima implementazione, dettando di volta in volta il design delle specifiche funzionalità, il progetto fu affidato alle mani di Junio Hamano, uno tra i contributori della prima ora, il più attivo a detta stessa di Torvalds.
La versione 1.0 di Git, infatti, nacque ad opera dello stesso Junio, che da 10 anni a questa parte continua a guidarne lo sviluppo. Fu lui a renderlo veramente utilizzabile dal grande pubblico, ed è grazie lui che oggi ogni “comune mortale” ne può fare un uso cosciente.
Al momento in cui stiamo scrivendo questo articolo, Git [11] è arrivato alla versione 2.10.
Grazie al lavoro di tanti, in questi anni Git ha saputo guadagnarsi un posto d’onore nel mercato dei DVCS, diventandone di fatto il re indiscusso nonostante la nutrita concorrenza. Senza averne la benché minima pretesa, ha poi di fatto reso possibile la nascita di un mercato prima inesistente, ovvero quello dei fornitori di servizi ad esso legati: aziende come GitHub, come Atlassian con BitBucket o come GitLab muovono oggi milioni di dollari, grazie a uno strumento abbozzato in un paio di mesi per risolvere un problema strettamente personale.
Conclusioni
Abbiamo voluto raccontare la storia di Git, affinché sia d’esempio a chi crede che per avere successo servano sempre grosse idee o investitori: la cosa importante è individuare un problema, e offrirne una soluzione, la migliore possibile.
Ah, un’ultima nota: BitKeeper è diventato open-source [12] dal maggio di quest’anno…