Git è un moderno sistema di controllo versione che offre le funzionalità di CVS o Subversion. Non solo. Git estende la nozione stessa di VCS (version control systems) grazie alla sua capacità di offrire quasi tutte le sue funzionalità per l’uso offline e senza un server centralizzato.
Git non è sinonimo di qualcosa… È nato da un’idea di Linus Torvalds nel 2005, il quale ha ammesso che Git può significare qualsiasi cosa, a seconda “del proprio umore”. È una combinazione casuale di tre lettere semplicemente pronunciabili e non effettivamente utilizzate da alcun comando UNIX comune. Il fatto che si tratti effettivamente di un errore di pronuncia della parola “get” può essere o non essere rilevante. La sua progettazione si ispira a strumenti analoghi come BitKeeper e Monotone. Oggi, gli sviluppatori di tutto il mondo stanno migrando a frotte verso questa piattaforma per le sue prestazioni efficienti, facilità e flessibilità di utilizzo, funzionalità offline e di collaborazione.
Il SubVersioning
Prima di parlare di Git, occorre aprire una breve parentesi sul subversioning. Il controllo versione (o appunto subversioning) è la gestione di versioni multiple di un insieme di informazioni. Gli strumenti software per il controllo versione sono ritenuti molto spesso necessari per la maggior parte dei progetti di sviluppo software. La cronologia di Wikipedia è un esempio di sistema di controllo versione. Viene usato prevalentemente nello sviluppo di progetti ingegneristici o informatici per gestire la continua evoluzione dei documenti digitali come il codice sorgente del software, i disegni tecnici, la documentazione testuale e altre informazioni importanti su cui può lavorare una squadra di persone.
DVCS: Controllo della Versione Distribuita
Se hai familiarità con uno o più sistemi tradizionali o centralizzati di controllo versioni come Subversion, ci saranno alcuni concetti chiave da fissare a mente e alcuni accorgimenti pratici da adottare per migrare a Git. Infatti, la peculiarità di Git è che non esiste un server centrale. La cronologia completa del repository è presente sulla macchina di ogni utente che ha clonato una copia del repository. Questa è l’essenza di un sistema di controllo versioni distribuito (DVCS).
Con Git è si può lavorare in modo completamente indipendente, mettendo in versione qualsiasi nuovo progetto, anche se in una fase “di incubazione”. La facilità di creare un nuovo repository Git (o ‘repo’ nel linguaggio comune) porta alla creazione di repository ovunque. Condividere un repository e un changeset direttamente con un collega sarà molto semplice, poichè non sarà necessario alcuna configurazione complicata, oppure un log-in a un server centrale. Basta semplicemente una connessione ad Internet. Git in pratica è peer-to-peer. Un po’ simile a BitTorrent per la condivisione dei file. E’ possibile trasmettere una serie di modifiche binarie tramite chiavetta USB, e-mail o in modo tradizionale, su una rete, utilizzando uno dei seguenti protocolli: HTTP, FTP, SCP, Samba, SSH o WebDAV. Iniziamo con Git.
Perché è necessario un sistema di controllo versione come Git?
I progetti software hanno tipicamente più sviluppatori che lavorano in parallelo. Quindi è necessario un sistema di controllo versione come Git per garantire che non vi siano conflitti di codice tra gli sviluppatori. Inoltre, i requisiti di tali progetti cambiano spesso, quindi un sistema di controllo versione consente agli sviluppatori di ripristinare e tornare a una versione precedente del codice.
Infine, a volte diversi progetti eseguiti in parallelo coinvolgono la stessa base di codice. In tal caso, il concetto di ramificazione (branch) in Git è molto importante.
Branching significa che il tuo progetto “diverge” dalla linea principale di sviluppo continuando a fare il lavoro senza fare confusione con la linea principale. In molti strumenti VCS, questo è un processo costoso, perchè spesso richiede di creare una nuova copia della directory del codice sorgente: ciò può richiedere molto tempo per progetti di grandi dimensioni. Il modo in cui Git ramifica è invece incredibilmente leggero, rendendo le operazioni di ramificazione quasi istantanee.
A differenza di molti altri VCS, Git incoraggia i flussi di lavoro che si ramificano e si uniscono spesso, anche più volte al giorno. Comprendere e padroneggiare questa funzione ti offre uno strumento potente e unico e può cambiare completamente il modo in cui sviluppi.
Differenza tra Git e GitHub
Come accennato in precedenza, Git è un sistema di controllo versione open source per la gestione e il monitoraggio dei progetti. È fondamentalmente uno strumento che gestisce la cronologia del codice sorgente. GitHub è invece il servizio di hosting per tutti i repository Git. In poche parole, Git è lo strumento, GitHub è il servizio per i progetti che utilizzano Git.
Panoramica molto veloce sull’uso di Git
Installare Git
Git è un applicativo molto leggero. Per la maggior parte delle piattaforme, è possibile copiare semplicemente i file binari in una cartella e configurare il PATH in modo che il comando Git sia eseguibile da riga di comando. Git è scritto principalmente in C, il che significa che esiste essenzialmente una distribuzione per ogni piattaforma supportata. Il riferimento canonico del programma di installazione può essere trovato su una pagina secondaria del sito ufficiale di Git all’indirizzo: git-scm.com/download.
Credenziali utente
Una volta installata la distribuzione opportuna, sarà necessario identificarsi con un nome utente e un indirizzo email per Git.
Git non supporta direttamente l’autenticazione o l’autorizzazione del repository., pertanto, le informazioni utente fornite durante la prima configurazione Git su una determinata macchina sono usate puramente per “accreditare” i contributi del codice. I comandi per identificarsi in Git sono i seguenti:
git config --global user.name "gianluca.tramontana" git config --global user.email "info@gianlucatramontana.it" git config --global color.ui "auto"
Creazione di un repository
Un repository è una raccolta completa di tutti i file e cartelle associati a un progetto, insieme alla cronologia delle revisioni di ciascun file. La cronologia dei file viene visualizzata come istantanee della sequenza temporale denominate “commit”. Ora che Git è installato e le informazioni dell’utente sono state stabilite, possiamo creare nuovi repository. Dal prompt dei comandi, creiamo una cartella vuota o accediamo ad una cartella contenente un progetto esistente che vogliamo mettere sotto controllo versione. Quindi inizializziamo la directory come repository Git digitando solamente tre comandi:
git init git add . git commit –m 'The first commit'
Il primo comando, init, crea una directory .git che contiene tutti i metadati e la cronologia del repository. A differenza di molti altri sistemi di controllo delle versioni, Git memorizza in modo univoco tutto in un’unica directory nella root del progetto. Quindi, nessun “inquinamento” nelle altre directory o sotto-directory.
Successivamente, il comando add con il carattere jolly punto indica a Git di inizializzare la directory corrente, i suoi file e tutte le sottocartelle, se presenti.
Infine, la funzione commit scrive in modo permanente i comandi precedenti nella cronologia del repository in un’azione transazionale. L’opzione -m fornisce preventivamente il messaggio di commit da salvare nella cronologia.
Clonare un progetto esistente
Un caso d’uso altrettanto comune per Git è quello di partire da un progetto esistente “puntando” al repository di qualcun altro. È importante capire che una “copia di lavoro” su Git è molto diversa dalla copia di lavoro che si ottiene da un repository SVN. A differenza di SVN, Git non fa alcuna distinzione tra la copia di lavoro e il repository centrale: sono tutti repository Git a pieno titolo (figura 1). Ciò rende la collaborazione con Git fondamentalmente diversa rispetto a SVN. Mentre SVN (figura 2) dipende dalla relazione tra il repository centrale e la copia di lavoro, il modello di collaborazione di Git si basa sull’interazione repository-to-repository. Invece di controllare una copia funzionante nel repository centrale di SVN, effettua i commit da un repository all’altro.
 figura 1 |
 figura 2 |
La sintassi per clonare una copia locale di un repository esistente è:
git clone ssh://john@example.com/path/to/my-project.git cd my-project
Il primo comando inizializza un nuovo repository Git nella cartella my-project sul computer locale e lo popola con i contenuti del repository centrale. Il secondo comando crea una cartella nel progetto per iniziare a modificare i file, a creare snapshot e interagire con altri repository.
Clonare un progetto su una specifica posizione
git clone <repo> <directory>
Clona il repository localizzato a <repo> nella cartella locale chiamata <directory>
Clonare un progetto con tag specifiche
git clone -branch <tag> <repo>
Clona il repository localizzato a <repo> ma clona solamente tutto ciò che si riferisce a <tag>. L’argomento -branch consente di specificare un ramo specifico da clonare anziché il ramo principale.
Protocolli URL usati in Git
SSH
Secure Shell (SSH) è un protocollo di rete ubiquitario autenticato che viene comunemente installato di default sulla maggior parte dei server. Poiché SSH è un protocollo con autenticazione, è necessario stabilire le credenziali con il server di hosting prima della connessione.
ssh://[user@]host.xz[:port]/path/to/repo.git/
GIT
E’ il protocollo unico per git. Git viene fornito con un demone che viene eseguito sulla porta (9418). Il protocollo è simile a SSH, tuttavia non ha AUTENTICAZIONE.
git://host.xz[:port]/path/to/repo.git/
HTTP
E’ il protocollo del web, più comunemente usato per il trasferimento di dati HTML di pagine Web su Internet. Git può essere configurato per comunicare su HTTP.
http[s]://host.xz[:port]/path/to/repo.git/
Per qualsiasi approfondimento, considerata la vastità dell’argomento, vi rimando alla consultazione del manuale ufficiale di GIT, qui.
