Ieri sera, per caso per noia per sport per imparare mi sono visto un video un po pesantino, si tratta del Tech Talk di Linus Torvalds su GIT, il suo SCM. Ho sempre sentito che Linus non sia un grande parlatore, nelal sua autobiografia dice che odia parlare, e cosí via. Devo dire che sono sorpreso moolto positivamente da Linus. Altroché pessimo parlatore, il suo Talk, anche se di 70 minuti abbondanti, é volato. Grazie ad una abbondante dose di coraggio e ironia, nonche un pizzico di arroganza e molta fiducia in se stesso, Linus riesce a trasformare un Talk technico come questo in una discussione interssante. Ora basta introduzione, eccovi il video:

Ebbene, per chi non ha la pazienza di vedersi tutto il talk, alcuni punti chiave. Dapprima cosa é importante affinché un SCM funzioni bene:

  • deve essere distribuito, e non centralizzato
  • deve avere delle prestazioni ottime (si lamenta che ci mette 3 secondi a fare la copia di 22.000 files)
  •  deve garantire che il file rimanga uguale, indipendentemente da intenzioni malignie, corruzione del disco o perdita di dati

Il trucco, a detta di Linus, sta nel fare il branching e il merge seguente molto semplice. Comedice Linus: “Quelli di SVN si vantano di avere un branching do O(1), peró l’O deve essere molto grande”. L’importante é che il merge sia semplice da fare, veloce e sicuro. Questo, assieme ad un “network of trust”, garantisce un efficenza incredibile. Il sistema funziona cosí: ogni volta che qualcuno fa un checkout, in realtá fa un branch del “master tree”. O di qualunque altro tree. Questo branch viene salvato localmente, e permette di lavorare parzialmente offline. Vista al velocitá di fare commit, la history al 100% affidabile e l’incredibile velocitá di merging di due branch, questo permetto uno stile di lavoro del tutto diverso. Dopo ogni cambiamento, anche solo minimale, si fa un commit. quando si é finito un pezzo di software,  si notificano gli amici fidati di quel che é stato fatto. Questi, a loro volta, possono “pullarsi” la versione modificate, e fare il merge dei due branch (il loro e quello modificato). Cosí, il mantenitore del “master tree” semplicemente riceve notifiche da 3-4 persone fidate quando queste hanno qualcosa di nuovo, e bisogna che lui controlli solo quelel quattro fonti e pulli da li. Con questo sistema si distribuisce il lavoro, visto che si possono creare dei “gruppi” specializzati che poi notificano gli altri quando é pronta una feature.

Un altro punto forte di git é che non vede “file”, ma solo contenuto. Non é solo capace di tracciare i movimenti di una funzione dentro ad un file, ma anche attraverso vari file. Anzi: visto questo approccio, git é piú efficente a trovare modifiche di un pezzo di codice anzicé di un file.

Ancora un due informazioni di sfondo: GIT é stato creato da Linus Torvalds, in meno di due settimane, dopo che ha provato vari prodotti (sia commerciali sia non) sul mercato e ha detto che neinte va bene. Viene usato in molti progetti Open Source ma non solo, primo fra tutti il Kernel di Linux. Sul sito ufficiale si trovano vari tutorial e informazioni.

Il sito é http://git.or.cz/. Fateci un salto.

p.s. E non dimenticate:

git clone git://git.kernel.org/pub/scm/git/git.git