Ci sono Strumenti che hanno Storie davvero Iconiche e Leggendarie, e proprio per questo, meritano di essere raccontate. E' infatti inconfutabile che alcune di queste storie raccontino come si cambia il Mondo, con Strumenti nuovi o Prodotti sensazionali. Git, oltre ad essere super utilizzato, è uno degli Strumenti più Straordinari che io abbia mai avuto il piacere di usare, e questa, è la sua Storia.
Salve Feelers e bentornati sul mio Blog! Io sono Lorenzo e in questo articolo vi racconterò la Storia di Git. Non temete, più avanti realizzerò anche una Guida su questo fantastico Software, non lasceremo le cose a metà "wink wink". Restate con me fino alla fine, perché ne vedremo delle belle, ma prima di cominciare, lasciate che vi inviti ad Iscrivervi al Canale, attivando la campanella degli avvisi e di lasciare un bel mi piace per supportarmi, ma non perdiamoci in chiacchiere e diamoci dentro!
Partiamo con la Definizione di Git. Git è un software per il controllo di versione distribuito (il cosiddetto versioning in gergo informatico inglese) utilizzabile da interfaccia a riga di comando, e creato da Linus Torvalds, l'inventore del kernel Linux, nell'ormai lontano 2005. Git nacque per essere un semplice strumento per facilitare lo sviluppo del kernel Linux ed è diventato uno degli strumenti di controllo di versione più diffusi sul pianeta. La sua progettazione si ispirò a strumenti (allora proprietari) analoghi come BitKeeper e Monotone, che sebbene offrivano alcune delle funzioni ricercate da Torvalds, non rispecchiavano in toto la sua visione di insieme e pertanto, le sue grandi esigenze da programmatore, lo portarono a creare questo nuovo strumento.
Anzitutto, cerchiamo di capire cosa significa il termine “Git”. E il miglior modo di iniziare è citare le parole del padre, Linus Torvalds:
"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 infatti, va anche detto che il termine “Git” può avere svariate altre accezioni, tra cui anche "idiota" o “a seconda dell’umore…”. Anzitutto, si tratta di una combinazione di tre lettere, facilmente pronunciabile e non usata da comandi UNIX, fattore importante visto che si usa da riga di comando. 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. Chi conosce la figura di Linus Torvalds, o ne ha seguito almeno un minimo le gesta, sa che questo è il suo stile: diretto, geniale e spesso irrispettoso.
Ma che cos'è Realmente Git? Andiamo per Gradi.
Git è un software per tenere traccia delle modifiche in qualsiasi insieme di file, solitamente utilizzato per coordinare il lavoro tra i programmatori che sviluppano in modo collaborativo il codice sorgente durante lo sviluppo di un determinato software. I suoi obiettivi includono velocità, integrità dei dati e supporto per flussi di lavoro distribuiti e non lineari (migliaia di rami paralleli in esecuzione su sistemi diversi). Detto in parole semplici per chi non mastica bene questo gergo di parole: Git permette a più Sviluppatori, a più Programmatori, di lavorare simultaneamente ad un Codice, e di collaborare, anche da Remoto, permettendo di tenere traccia del loro operato e dei vari flussi di lavoro.
Come ci riesce?
Attraverso i Branch: i Rami. Quando si lavora ad un codice, ogni sviluppatore crea una sua istanza, ne fa sostanzialmente una copia, per poterci lavorare. In questo modo, si creano diversi "rami" dello stesso albero genitore, che permette a più sviluppatori di riuscire a creare codice partendo dallo stesso progetto. Quando vengono effettuate delle modifiche sostanziali, che quindi devono essere "caricate", passatemi il termine, si eseguono i comandi per unire i branch, ovvero si salva e si carica il codice su quello precedente, che viene quindi sovrascritto con una sua nuova versione. Questo è molto utile per avere dei flussi di lavoro paralleli e indipendenti, in cui possiamo sperimentare nuove funzioni o correggere bug senza intaccare il progetto principale e poi, eventualmente, unirli (con il merge) nel ramo principale o in altri rami. Git incentiva molto l’uso dei branch, e infatti rendono il lavoro molto più agile e semplice da gestire.
Ma come nasce Git? Qual è la Sua Storia? Da quale esigenza è nato uno strumento che è diventato Fondamentale nella vita di uno Sviluppatore Software? \\
Lo sviluppo di Git è iniziato nell'aprile 2005 sotto le mani esperte di Linus Torvalds. Il perché sia avvenuta questa invenzione è molto avvincente, ma necessita di qualche piccola precisazione tecnica. Linux, il kernel più famoso del mondo della tecnologia, consta di qualche milione di linee di codice; avendo a che fare con una simile mole di dati, non risulta difficile capire quanto possa essere importante avere un sistema di versioning preciso, veloce ed efficiente. Ma soprattutto veloce. Prima dell’avvento di Git il ruolo di versioning del codice era affidato a BitKeeper, un Distributed Version Control System (DVCS) proprietario, sviluppato da BitMover Inc.; con a capo della società un signore di nome: Larry McVoy, il creatore di quello che ad oggi possiamo definire il primo DVCS della storia.
Leggenda vuole 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. Ovvero la difficoltà ad aggiornarsi velocemente man mano che il progetto cresceva di dimensioni. In quel periodo Linus si occupava di integrare manualmente tutte le modifiche che venivano proposte per il kernel, modifiche che gli venivano recapitate esclusivamente via mail. Riuscita ad immaginare come si può mantenere un progetto da milioni di linee di codice via email? Follia Pura!
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 un particolare e preciso punto: Linus è uno solo, e non possiamo averne più di uno, pertanto va aiutato. Quello che si può fare per migliorare la situazione è 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, ovvero un Sistema di Versioning.
L’offerta non fu accettata prima del 2002, in quanto comunque il Team di sviluppo era titubante, nonostante il Progetto fosse rodato e collaudato, e comunque non fu adottato senza voci contrarie; non stupisce quindi se la collaborazione durò solo 3 anni. Nel 2005 infatti, i rapporti si ruppero del tutto a causa di alcuni incresciosi episodi. Larry McVoy accusò Andrew Tridgell (Un Collaboratore al Progetto Linux) e figura di spicco nel mondo Open Source, di portare avanti un progetto di reverse-engineering del codice di BitKeeper, violando così gli accordi stabiliti di protezione del codice di BitKeeper durante l'uso dello strumento per lo sviluppo del kernel. 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 la sua architettura. Addirittura ne era stato proibito l’uso a chiunque collaborasse con gli Open Source Development Labs (OSDL); tra questi collaboratori, il più famoso era certo Andrew Morton, il braccio destro di Linus Torvalds. Fu così che quindi, McVoy, decise di revocare per sempre e a tutti la licenza di uso gratuito di BitKeeper troncando irrimediabilmente i rapporti con il Team di Sviluppo e permettendo lo sviluppo di Git e di un altro sistema di controllo delle versioni, Mercurial.
Alla conferenza Linux del 2005, Tridgell poi, dimostrò nel suo intervento che il procedimento di "reverse engineering" che aveva usato era semplicemente collegarsi con telnet alla porta appropriata di un server Bitkeeper e digitare "help". Non di certo un qualcosa di così difficile da fare!
Fu così che di punto in bianco, il Progetto Mastodontico di Linus Torvalds, si trovò senza Sistema di Controllo del Codice Sorgente, e ne aveva un bisogno estremo. Nel gruppo di lavoro di Linux, però, ci fu chi considerò l’avvenimento come una salvezza. MNon tutti amavano BitKeeper, in definitiva un prodotto proprietario e, per molte persone, questa rottura fu senz’altro un evento positivo, una liberazione dalle stringenti e dittatoriali regole imposte da McVoy.
Fra chi fu contento di tale rottura, annoveriamo i famosissimo Richard Stallman e Alan Cox, personaggi di spicco del mondo del Free Software. Essi sollevarono delle perplessità fin dal primo momento, legate soprattutto al fatto di ritenere inappropriato l’uso di software proprietario per lo sviluppo di codice libero, una cosa ideologicamente contraddittoria. Fu così che, mentre correva l’anno 2005, iniziò la ricerca di un’alternativa, ma soprattuto nacque una Leggenda. Linus Torvalds, voleva un sistema distribuito che potesse usare come BitKeeper, alla quale ormai si era così dannatamente abituato, ma nessuno dei sistemi gratuiti disponibili soddisfaceva pienamente le sue esigenze. Certo, il Mondo Open Source metteva a disposizione diversi Concurrent Version System o CVS, ovvero sistemi ormai "antichi" di versionamento del codice, ma Torvalds notò che un sistema di gestione del controllo del codice sorgente a quei tempi, poteva richiedere 30 secondi per applicare una patch e aggiornare tutti i metadati associati, quindi per applicare un aggiornamento al codice, e ciò non si poteva adattare alle esigenze dello sviluppo del kernel Linux, dove la sincronizzazione con altri manutentori del codice potrebbe richiedere 250 volte questa stessa operazione. Sistemi del genere, avrebbero rallentato tantissimo lo Sviluppo del Kernel, e questo lui non poteva permetterlo.
Torvalds però non aveva una buona opinione di CVS, voleva un sistema distribuito che potesse usare come BitKeeper, ma nessuno dei sistemi disponibili gratuitamente soddisfaceva i suoi bisogni, particolarmente il suo bisogno di velocità. Partì quindi da quello che non voleva per creare Git, partì da tutto ciò che CVS non doveva essere.
I punti focali sui quali fondare lo sviluppo di Git, per Linus furono:
1) “Prendere Concurrent Versions System (CVS) come esempio di quello che non va fatto; nel dubbio, fare delle scelte in senso esattamente contrario”. Rimarcando il suo disprezzo per lo strumento.
In un famoso talk del 2007, 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". Abbiamo detto tutto. Tuttavis Linus non disprezza CVS senza motivo. 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.
Odio trasmesso anche ad altri strumenti, come Subversion, il CVS "migliorato". 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”.
2) Supporto di un flusso di lavoro distribuito, simile a BitKeeper. Come BitKeeper, Git non usa un server centralizzato.
3) Salvaguardia dalla corruzione dei dati, sia accidentale che intenzionale
4) Altissime prestazioni
Fu così quindi che venne presa la decisione di creare un DVCS ex novo che rispettasse i canoni richiesti per lo sviluppo di un progetto come il kernel Linux. Ecco la nascita della Leggenda. Nella sua Prima Mail durante la creazione di Git, si rese conte che, gli strumenti software di versioning che giravano a quel tempo non riuscivano ad essere particolarmente performanti in termini di velocità, e potevano far slittare il lavoro di moltissimi progetti, soprattutto se particolarmente attivi. La "soluzione" era BitKeeper, che sebbene fosse il doppio più veloce degli altri software, restava comunque lento per progetti grandi, in quanto, passare da 30 a 15 secondi di latenza tra il caricamento di una patch e l'altra comunque avrebbe fatto ritardare lo sviluppo del codice! Tuttavia, la sua peculiare semplicità di merge (ovvero di unione di diversi rami del codice) permetteva di rendere accettabile questo ritardo. Tuttavia, il più grande problema di Linus, era che BitKeeper non era accessibile, in quanto non più concesso in forma gratuita e pertanto si necessitava di un nuovo strumento, maggiormente performante. Un qualcosa che tenesse in mente come variava il codice, quale fosse la versione 1.0 e la versione 1.1 e quale fosse la loro differenza, ma soprattutto a Linus Torvalds serviva un qualcosa di ultra veloce.
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 fu Junio Hamano.
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 esperte di Junio Hamano, uno degli sviluppatori più attivi del Progetto Linux. La versione 1.0 di Git, nacque dalle sue mani, e da 10 anni a questa parte continua a guidarne lo sviluppo ininterrotto. Fu lui a renderlo veramente utilizzabile dal grande pubblico, ed è grazie lui che oggi ogni “comune mortale” ne può fare un uso cosciente. Grazie al lavoro di tantissimi, Git ha saputo guadagnarsi un posto d’onore nel Panorama dei DVCS e del Mondo Informatico Tutto. 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 (ricordiamo ora di proprietà Microsoft), 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 e dell'ultimo secondo.Abbiamo quindi visto che per avere successo, non servono necessariamente grosse idee o grandi investitori: la cosa importante è individuare un problema, e offrirne una soluzione, la migliore possibile.
Ah! Quasi Dimenticavo "wink wink" BitKeeper è diventato open-source dal 9 maggio 2016, arrendendosi di fatto a questo modello di business.
Piaciuta questa Storia? Fatemelo sapere con un commento! Se avete dubbi o consigli o se volete suggerirmi il tema del mio prossimo video, scrivetelo sempre qui sotto nei commenti! Io vi ringrazio, e noi, ci vediamo alla prossima!