Git
Chapters ▾ 2nd Edition

1.1 Per iniziare - Il controllo di versione

In questo capitolo muoveremo i primi passi con Git. Inizieremo con una panoramica sui diversi strumenti per il controllo delle versioni per poi vedere come installare, configurare e usare Git sul tuo sistema. Alla fine di questo capitolo saprai perché è nato Git, perché dovresti usarlo e come configurarlo per usarlo al meglio

Il controllo di versione

Cos’è il "controllo di versione", e perché dovrebbe interessarti? Il controllo di versione è un sistema che tiene traccia, nel tempo, di tutte le modifiche a un file o un insieme di file, così che sia possibile recuperare una qualsiasi versione precedente in qualsiasi momento. Per gli esempi di questo manuale versioneremo dei file di codice sorgente, ma in pratica potrai eseguirli con qualsiasi tipo di file che sia sul tuo calcolatore.

Se sei un grafico o un web designer e vuoi mantenere traccia di tutte le versioni di una immagine o di uno schema/layout (e molto probabilmente è ciò che vuoi), un sistema di controllo delle versioni (VCS - Version Control System in inglese) è una saggio strumento da usare. Ti permette di recuperare un file in uno stato precedente, tornare indietro con tutto il progetto a una versione precedente, confrontare le modifiche fatte nel tempo, vedere chi ha modificato qualcosa che può causare problemi, chi e quando ha introdotto un problema e molto altro. Usando un VCS significa anche che se fai un macello o perdi qualche file, generalmente, puoi recuperare facilmente il tuo lavoro. E tutto questo lo ottieni con pochissima fatica.

Sistemi locali di controllo di versione

Il sistema preferito da molte persone per gestire le versioni è copiare i file in un’altra cartella (magari chiamandola con la data della copia, se sono furbi). Questo approccio è comunissimo perché molto semplice, ma è incredibilmente soggetto a errori. È facile dimenticare in quale directory sei e modificare il file sbagliato o copiare dei file che non volevi.

Per far fronte a questo problema, molto tempo fa, dei programmatori svilupparono dei VCS locali che avevano un database semplice che registrava tutte le modifiche ai file controllati

Diagramma di un sistema locale di controllo
Figure 1. Local version control.

Uno dei più popolari VCS era un sistema chiamato RCS, che ancora oggi si trova in molti computer. Anche il famoro Mac OS X installa il comando rcs quando installi gli strumenti di sviluppo (Developer Tools). RCS salva in un formato speciale sul disco una serie di patch (ovvero le differenze tra i file) tra una versione e l’altra. In questo modo può ricreare lo stato in cui era un qualsiasi file in qualsiasi preciso momento, aggiungendo una dopo l’altra le varie patch.

Sistemi centralizzati di controllo di versione

Il successivo grosso problema da risolvere riguarda la necessità di collaborare con sviluppatori che usino altri sistemi. Per risolverlo nacquero i sistemi centralizzati di controllo di versione (CVCS - Centralized Version Control Systems in inglese). Questi sistemi, come CVS, Subversion, e Perforce, hanno un unico server che registra tutte le versioni dei file controllati, e un numero di utenti che scaricano i file dal quel server centrale. Questo è stato lo standard per il controllo di versione per molti anni

Diagramma del controllo centralizzato di versione
Figure 2. Il controllo centralizzato di versione.

Questa configurazione ha parecchi vantaggi, specialmente rispetto ai VCS locali. Tutti sanno, con una certa approssimazione, cosa fanno le atre persone di un progetto.Gli amministratori hanno un controllo preciso su chi può fare cosa, ed è molto più facile amministrare un CVCS che un database locale su ogni client. Gli amministratori hanno un controllo preciso su chi può fare cosa, ed è molto più facile amministrare un CVCS che un database locale su ogni calcolatore.

Questa configurazione ha però numerosi svantaggi. Il più ovvio è che il server centralizzato è il punto di rottura del sistema. Se il server va giù per un’ora,nessuno può collaborare o salvare una nuova versione di qualsiasi cosa su cui sta lavorando finché non viene ripristinato. Se si danneggia il disco rigido del database centrale e non ci sono dei backup adeguati, perdi assolutamente tutto: tutta la cronologia del progetto ad eccezione delle singole istantanee (snapshot in inglese) che le varie persone possono avere sulle loro macchine locali. Anche i sistemi locali di VCS hanno lo stesso problema: ogni volta che conservi tutta la cronologia di un progetto in un unico posto, rischi di perdere tutto.

Sistemi distribuiti di controllo di versione

Ed è questo il momento in cui entrano in scena i sistemi distribuiti di controllo ((DVCSs - Distributed Version Control Systems). In un DVCS (come Git, Mercurial, Bazaar o Darcs), i membri del gruppo non solo scaricano l’ultimo stato dei file, ma copiano tutto il repository completo. In questo modo se un server si rompesse mentre i sistemi ci stavano interagendo, da qualsiasi calcolatore sarà possibile ricopiare il contenuto per ripristinare l’intero repository. Ogni clona è un backup completo di tutti i dati.

Diagramma del controllo distribuito di versione.
Figure 3. Controllo distribuito di versione.

Molti di questi sistemi, inoltre, gestiscono bene molteplici repository remoti. Così puoi lavorare contemporaneamente allo stesso progetto con persone o gruppi diversi Questo ti permette di avere diversi tipi di flussi di lavoro, che non sono possibili in sistemi centralizzati, come i modelli gerarchici.