Archivio Domande

Git è un sistema software di controllo di versione distribuito, creato da Linus Torvalds nel 2005.

La progettazione di Git è stata ispirata da BitKeeper e da Monotone, pensato inizialmente solamente come motore a basso livello che altri potevano usare per scrivere un front-end. In seguito diventato un sistema di controllo versione, direttamente utilizzabile da riga di comando; vari progetti software adesso usano Git per tale attività, principalmente il kernel Linux.

Storia

Lo sviluppo di Git è iniziato dopo che molti sviluppatori del kernel di Linux sono stati costretti ad abbandonare l'accesso ai sorgenti tramite il sistema proprietario BitKeeper. La possibilità di utilizzare BitKeeper gratuitamente era stata ritirata dal detentore dei diritti d'autore Larry McVoy dopo avere sostenuto che Andrew Tridgell aveva effettuato il reverse engineering dei protocolli.

Alla conferenza Linux.Conf.Au del 2005, Tridgell 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".

Torvalds 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à. Ecco un messaggio e-mail che scrisse il 7 aprile 2005 mentre stava scrivendo il primo prototipo, tradotto in italiano:

Tutti i sistemi di controllo versione che ho preso in considerazione rendono [il lavoro] difficile. Una delle cose (in realtà, la cosa principale) a cui ho lavorato è rendere quel procedimento realmente efficiente.

Se ci vuole mezzo minuto per applicare una patch, e ci si deve ricordare i confini delle modifiche applicate, ecc. (e francamente, si potrebbe considerare mezzo minuto poco per la maggior parte dei sistemi di controllo versione che ci sono in giro, e per un progetto della dimensione di Linux), allora una serie di 250 e-mail (che non è affatto inaudito quando mi sincronizzo con Andrew, per esempio) richiede due ore. Neanche BitKeeper si dimostrò rapido (in effetti, confrontato a qualunque altra cosa, BitKeeper è velocissimo, spesso uno o due ordini di grandezza migliore), e richiedeva circa 10–15 secondi per ogni e-mail quando facevo il merge con Andrew. Tuttavia, con BitKeeper quello non era un problema tanto grosso, dato che i merge BitKeeper<->BitKeeper sono più semplici, e non ho mai dovuto fare un più lento merge manuale con gli altri sviluppatori principali.

Perciò il merge, in un sistema di controllo versione basato sull'applicazione di patch dovrebbe essere più veloce di BitKeeper. Il che è veramente veramente difficile. E per questo sto scrivendo alcuni script per tentare di tener traccia delle cose in modo nettamente più veloce.

Le indicazioni iniziali sono che dovrei essere in grado di farlo con la stessa velocità della sola applicazione delle patch. Ma francamente, sono al massimo a metà del lavoro, e se mi imbatterò in qualche ostacolo può darsi che non sarà affatto così. La ragione per cui posso fare questo così velocemente è che i miei script non saranno un sistema di controllo versione, saranno un tipo di cosa molto specifica del tipo “log dello stato di Linus”. Ciò renderà il merge tramite patch molto più veloce, e quindi fattibile.

(Se per applicare una patch ci vogliono tre secondi, anche una lunga serie di patch non è un problema: se vengo avvertito entro uno o due minuti che il merge è fallito a metà strada, va bene, in tal caso posso procedere a correggerlo a mano. Questo è il motivo per cui la latenza è critica — se dovessi fare le cose del tutto “offline”, per definizione non sarei in grado di correggere i problemi quando accadono).

Linus aveva vari criteri di progettazione:

1. Prendi CVS come esempio di che cosa nonfare; se hai un dubbio, fai l'esatto contrario. Per citare Linus, che parlava un po' ironicamente:

   “Per i primi 10 anni di manutenzione del kernel, usavamo letteralmente tarball (archivi compressi) e patch, che è un sistema di gestione del codice sorgente molto migliore di CVS. Poi ho finito per usare CVS per 7 anni in un'azienda [presumibilmente Transmeta] e lo odio appassionatamente. Quando dico che odio CVS appassionatamente, devo anche dire che se ci sono utenti SVN (Subversion) tra il pubblico, potreste volervene andare. Perché a causa del mio odio di CVS ritengo Subversion il progetto meno sensato che sia mai cominciato. Per un po' lo slogan di Subversion era ‘CVS fatto bene’, o qualcosa di simile, e se incominci con quel tipo di slogan, non puoi andare da nessuna parte. Non c'è modo di fare CVS bene.”

2. Supporto di un flusso di lavoro distribuito, simile a BitKeeper. Come BitKeeper, Git non usa un server centralizzato.

   “BitKeeper non è solamente il primo sistema di controllo dei sorgenti che abbia mai pensato che valesse la pena usare; è stato anche il sistema che mi ha fatto capire perché ce ne sia effettivamente bisogno, e come si possa operare in modo efficace. Perciò, sebbene da un punto di vista tecnico Git sia molto diverso da BitKeeper (il che era un altro obiettivo di progettazione, perché volevo rendere chiaro che non era un clone di BitKeeper), molti dei procedimenti che usiamo con Git vengono direttamente dai procedimenti che abbiamo imparato da BitKeeper.”

3. Salvaguardia dalla corruzione dei dati, sia accidentale che intenzionale
4. Altissime prestazioni

I primi tre criteri non erano soddisfatti da alcun preesistente sistema di controllo versione eccetto Monotone, e il quarto ha escluso anche Monotone. Perciò, immediatamente dopo lo sviluppo della versione 2.6.12-rc2 del kernel di Linux, si è dedicato a scrivere il suo.

Lo sviluppo di Git è cominciato il 3 aprile 2005. Il progetto è stato annunciato il 6 aprile 2005, ed è stato usato per gestire il proprio sorgente a partire dal 7 aprile 2005. La prima fusione di più branch in uno è stata fatta il 18 aprile 2005. Torvalds ha raggiunto i suoi obiettivi in termini di prestazioni: il 29 aprile 2005, Git riusciva ad applicare 6 o 7 patch a Linux in un secondo. Il 16 giugno 2005 è stata pubblicata la versione 2.6.12 del kernel di Linux, la prima gestita con Git.

Sebbene fortemente influenzato da BitKeeper, Torvalds ha deliberatamente tentato di evitare approcci convenzionali, il che ha prodotto un sistema molto innovativo.

Torvalds ha sviluppato il sistema fino a quando è diventato usabile da utenti tecnici, poi, il 26 luglio 2005, ha ceduto la manutenzione a Junio Hamano, un importante contributore al progetto. Hamano è stato il responsabile della versione 1.0, pubblicata il 21 dicembre 2005, e rimane oggi il manutentore.