Più di 10 anni fa, la community di sviluppo del kernel Linux si trovò dinanzi un problema: il sistema di controllo delle versioni BitKeeper aveva interrotto la loro licenza e nessun altro sistema andava più bene per i loro bisogni. Linus Torvalds, il mitico creatore di Linux, prese la situazione in mano e sparì per un intero weekend per riemergere la settimana seguente con Git. Oggi Git è sicuramente il sistema più usato e richiesto nella gestione delle versioni.
Noi abbiamo dedicato un’intera e completa guida a Git e sul come gestire le versioni del software. Se siete qui per imparare, dategli uno sguardo!
Per celebrare questo traguardo, il sito Linux.com ha intervistato Linux Torvalds chiedendogli qualche storia behind-the-scenes e in generale cosa ne pensa dello stato attuale del progetto. Noi vi riportiamo qui questa intervista, tradotta integralmente.
Perché hai creato Git?
Non ho mai davvero pensato e voluto realizzare un sistema di gestione dei sorgenti, e penso che sia la cosa meno interessante in tutta l’informatica (con la possibile eccezione dei database). Ho odiato tutti i sistemi profondamente. Ma poi BitKeetper è arrivato e ha cambiato questa visione che avevo del controllo di versione. BitKeeper ha la maggior parte delle funzioni necessarie e in più offre il merge tra il repository locale e quello remoto ed è davvero una gran cosa. Il fatto che il controllo fosse distribuito ha fatto sparire di colpo i vecchi problemi che avevano gli altri sistemi e tutta la questione del “chi può cambiare cosa”. Mostrò che tutto questo poteva essere evitato semplicemente facendo lavorare ognuno su un repository locale. Certo, aveva i suoi problemi: c’erano alcune scelte tecniche che causavano problemi (rinominare i file era terribile), ma il principale lato negativo era il fatto che siccome non era open source, c’erano un sacco di persone che semplicemente si rifiutavano di usarlo. Così, mentre diversi sviluppatori usavano BitKeeper (perché è gratuito per i progetti open source), non era usato da altri. Ci ha molto aiutato nello sviluppo del kernel, ma resistevano piccoli punti da risolvere.
Si arrivò a un punto quando Tridge (Andrew Tridgell) cominciò a fare il reverse-engineering del (relativamente) semplice protocollo di BitKeeper, cosa che era contro le norme d’uso del software. Ho passato diverse settimane (ma a me sono sembrati mesi) provando a fare da mediatore tra Tridge e Larry McVoy (il capo di BK, ndr) ma alla fine la cosa non funzionò. Così ad un certo punto ho deciso di non poter continuare a utilizzare BK, ma neanche di voler tornare ai tempi bui pre-BK. Tristemente, al tempo, anche se c’erano altri sistemi che provavano ad implementare la logica del software distribuito, nessuno lo faceva davvero bene, soprattutto in remoto. Anche le performance che volevo nel trasferimento dati in remoto non erano soddisfacenti, e inoltre ero preoccupato dell’integrità del codice. Così ho semplicemente deciso di scrivere un sistema nuovo.
Qual è stato il tuo approccio? Sei stato sveglio tutto il weekend o l’hai scritto in orario di lavoro?
Heh. Puoi vedere da te come ha preso forma guardando la storia del repository di Git stesso. C’è voluto circa un giorno per arrivare ad essere “self-hosted” così da poter usare Git per sviluppare.. Git. Il primo giorno quindi, i commit erano, diciamo, nascosti, ma tutto era già lì. Ho lavorato maggiormente durante il giorno, ma se guardate ci sono due istantanee fatte verso la mezzanotte e un paio alle 2. La parte più interessante però è sul quanto velocemente ha preso forma; il primo vero commit nel repository non contiene molto codice, ma poteva già eseguire il commit di se stesso. Il vero trucco però è sul come organizza i dati.
Ho provato a stressare il sistema fin tanto che prendeva forma in circa 10 giorni (a quel punto ho provato a fare il mio primo commit del *kernel*), ma non sono finito nella pazzìa del programmare senza sosta. Infatti la prima versione è abbastanza piccola, non è composta da molto codice, perché tutto dipendeva dal fatto che l’idea base fosse buona. Ci avevo pensato su per un po’ prima che l’intero progetto iniziasse. Avevo visto i problemi che altri avevano. Avevo visto quello che volevo evitare.
Ha raggiunto le tue aspettative? Come sta funzionando oggi secondo te? Ci sono limitazioni?
Sono molto contento di Git. Funziona notevolmente bene per il kernel e sta ancora soddisfacendo tutte le mie aspettative. Quello che mi sembra interessante è il modo in cui è stato adottato da così tanti altri progetti. Sorprendentemente veloce. C’è molta resistenza nel cambiare il sistema di controllo della versione, basta guardare quanto tempo CVS e anche RCS sono rimasti in giro, ma ad un certo punto Git ha preso il sopravvento.
Quale pensi sia il motivo di questa grande diffusione?
Penso che molti altri si siano sentiti frustrati dagli stessi problemi che mi hanno fatto odiare SCM e, sebbene ci siano stati molti progetti che tentassero di risolvere uno o due piccoli casi che facevano impazzire la gente, non c’era veramente niente di simile a Git che davvero affrontasse di petto questi problemi. Anche se molti non capirono l’importanza della parte riguardante la logica “distribuita” (e molti la contrastavano), una volta che si resero conto che ciò consentiva backup semplici e affidabili e che tutti potevano avere i propri repository di test privati senza preoccuparsi di alcuna politica sui permessi del “chi fa cosa”, adottarono Git senza voltarsi indietro.
Git durerà per sempre o prevedi un altro sistema fra altri 10 anni? Sarai ancora tu a scriverlo?
Non lo scriverò io, no. E forse vedremo qualcosa di nuovo in dieci anni, ma vi garantisco che assomiglierà sicuramente a Git. Non che Git sia perfetto, ma ha realmente aggiustato tutti i problemi basilari degli altri sistemi.
Nessuna falsa modestia 😉
Perché Git funziona così bene per lo sviluppo di Linux?
Beh, è stato ovviamente progettato per il nostro flusso di lavoro, quindi è parte di esso. Ho già citato molte volte l’intera parte “distribuita”, ma vale ripeterla. È stato anche progettato per essere abbastanza efficiente per un progetto grandicello come Linux, ed è stato creato per fare cose che la gente considerava “difficili” prima di Git – perché queste sono le cose che anche *io* faccio ogni giorno.
Giusto come esempio: il concetto di “fusione” tra rami viene generalmente considerato qualcosa di complesso e difficile nella maggior parte degli SCM. Si dovevano pianificare i merge con calma, perché potevano essere distruttivi. Questo per me non è accettabile, dal momento che quotidianamente faccio decine di merge e il problema a cui devo dedicarmi è testare il risultato del mio codice, non perdere tempo sul merge stesso. La “parte Git” del mio lavoro dura giusto un paio di secondi, di solito ci vuole di più solo per scrivere la spiegazione del merge. Quindi Git è stato fondamentalmente progettato e scritto per i miei requisiti, e si vede.
Molte persone sostengono che Git è solo per persone super intelligenti. Anche Andrew Morton ha detto che Git è “espressamente progettato per farti sentire meno intelligente di quello che tu pensi di essere.” Qual è la tua risposta a questo?
Penso che sia stato vero in passato, ora non più. Ci sono diverse ragioni per le quali le persone si sono sentite così, una sola però è rimasta: “puoi fare le cose in tanti modi”.
Puoi fare molte cose con Git perché molte funzioni sono state create per lavorare insieme ad altre persone. Git comprende un set di strumenti molto potenti e spesso all’inizio ci si può sentire sopraffatti, però questo offre anche il vantaggio che la stessa operazione si può fare in modi diversi, e tutti “funzionano”. Generalmente il modo migliore di imparare Git è iniziare con comandi molto semplici e non guardare neanche le altre funzioni finché non si è abbastanza bravi con le basi.
Ci delle ragioni storiche per le quali Git è stato spesso considerato complicato. Una di queste è che è stato davvero complicato. Le persone che hanno iniziato a usare Git molto presto (per lavorare sul kernel), hanno dovuto apprendere davvero un insieme molto scomodo di script per far funzionare tutto. Questo perché tutto lo sforzo all’inizio fu indirizzato per far funzionare “la tecnologia di base” e poco per renderlo semplice. Così Git (meritatamente) si è fatto una brutta fama all’inizio, perché dovevi sapere esattamente cosa stavi facendo. Tutto questo è stato vero soltanto per i primi sei mesi, forse un anno.
L’altro grande motivo che ha fatto pensare che Git fosse difficile è che Git è molto diverso dagli altri sistemi. Ci sono molti sviluppatori che hanno usato CVS (o altri) per un decennio o due. Git non è CVS, neanche lontanamente. I comandi sono diversi. Non abbiamo neanche immaginato di farlo simile a CVS, anzi il contrario. E se hai usato un sistema CVS-like per molto tempo, è ovvio che Git possa apparirti complicato e stranamente diverso. Perché le mie versioni sono basate su un HEX da 40 caratteri e non su una stringa tipo “1.3.1.”?
Git però non è “inutilmente diverso”. Le differenze sono necessario. È solo che ha fatto alcune persone pensano che sia più complicato di quanto lo sia perché provengono da un background molto diverso. La fortuna è che là fuori molti programmatori non hanno neanche mai usato CVS, e il loro prima sistema è proprio Git.
Pensi che lo sviluppo del kernel Linux sarebbe potuto crescere così rapidamente senza Git? Perché sì o perché no?
Beh, “senza Git” di sicuro. Ma avrebbe richiesto che qualcun altro, prima o poi, avesse creato qualcosa di equivalente: un sistema di controllo delle versioni distribuite efficace proprio come Git. Avremmo sentito certamente il bisogno di qualcosa *come* Git.
Qual è la tua opinione su GitHub?
GitHub è un eccellente servizio di hosting. Non ho niente contro. Ora, le lamentele che ho avuto riguardo GiHub come piattaforma di sviluppo- ovvero fare commit, pull, tenere traccia dei bug, etc. – sono che non funziona molto bene per tutti. Non è nemmeno vicino, purtroppo, neanche per il kernel: è troppo limitato.
Questo è in parte a causa del modo in cui il kernel viene sviluppato, ed in parte è dovuto al fatto che certe interfacce di GitHub incoraggiano i cattivi comportamenti. I commit fatti su GitHub, per esempio, hanno messaggi scritti male, proprio perché l’interfaccia non blocca questa prassi. Fixando questi dettagli il tutto lavorerà sicuramente meglio, ma difficilmente sarà appropriato per il kernel linux.
Qual è l’utilizzo più interessante che hai visto per Git e/o GitHub?
Sono contento che abbia reso così facile avviare un nuovo progetto. L’hosting è sempre stato un punto ostico, e con Git e GitHub è quasi banale creare un piccolo progetto dal nulla. Non importa quale sia il progetto: quello che conta è che tu lo puoi fare.
Hai progetti laterali, attualmente? Magari un software ancora più brillante che dominerà lo sviluppo del software per gli anni a venire?
Niente di programmato. Ma vi terrò aggiornati.
