Impariamo in 5 minuti ad usare GIT, il più potente e flessibile sistema di controllo versione che può essere utilizzato negli ambiti più disparati. Insomma se avete files soggetti a modifiche, questo è il modo migliore per non perderli e mantenerne la storia!

Cos’è un Sistema di Controllo di Versione?

Non è altro che un sistema che consente di tenere traccia di tutte le modifiche ai files e di recuperare vecchie versioni che altrimenti verrebbero perse. Quindi un sistema di backup intelligente che consente all’utente di revisionare una qualsiasi directory.
Questo è particolarmente utile nella programmazione perchè molte persone lavorano sullo stesso progetto e modificano continuamente gli stessi files, creando così conflitti che un VS aiuta a risolvere effettuando l’unione delle modifiche fatte da diverse persone. E’ utilizzato molto nel bug-fixing poichè consente di creare rami alternativi (vedi sotto) che possono poi essere uniti (merge) con la versione ufficiale.

Perchè GIT?

Perchè è stato sviluppato da Linus Torvalds (l’inventore di Linux) ed è ormai utilizzato nella maggioranza dei progetti informatici, è facile da usare, multi-piattaforma, bisogna solo imparare i comandi base e può essere utilizzato con diversi servizi online che offrono spazio gratuito per i propri progetti.
A differenza di CVS che aveva un repository centralizzato, GIT è un sistema distribuito dove ogni utente/sviluppatore ha una copia dell’intero repository sulla sua macchina, completa di tutte le versioni salvate (da quando è nato il progetto!).

Come si installa e si usa GIT?

Dal sito ufficiale Git-Scm è possibile scaricare l’ultima versione stabile per Windows/Linux/Mac o Solaris.
Installandolo comparirà un’icona sul desktop, la “GIT BASH” simile alla shell di DOS.

Con GIT si fa tutto da linea di comando, ma esistono programmi che consentono di utilizzarlo attraverso un’interfaccia grafica intuitiva (come SmartGit, Tortoise, SourceTree, etc.). Ovviamente il  maggior controllo si ha utilizzandolo da linea di comando.

Nella GIT BASH comparirà il vostro nome utente/pc, la directory su cui siete posizionati, e il ramo su cui si sta lavorando (master è il ramo principale):

utente@pc-name directory (master)
$

Per cambiare directory basta usare i comandi (uguali al DOS)

cd C:/project
cd .. (per salire di cartella)

Come ragiona GIT?

Sia che lo usate da linea di comando, sia che lo usate attraverso interfaccia grafica, dovete prima capire come ragiona GIT per evitare brutte sorprese, ad esempio perdere tutti i file di un progetto!! GIT è molto potente quindi è necessario avere una certa attenzione.

GIT ragiona per versioni, ogni volta che volete salvare una nuova versione dei vostri files dovete effettuare un COMMIT cioè una fotografia che viene salvata nel Repository.

Il principio di funzionamento (three states) è semplice:

1. la working directory è la directory dove lavorate e modificate i file (la directory del vostro progetto)
2. la staging area è un’area dove preparate una copia (snapshot) dei file quando volete salvare una nuova versione
3. con il commit i file presenti nella staging area vengono salvati in modo permanente nella .git directory (il Repository) che contiene tutta la storia del progetto

A livello operativo:

• il comando git add  inserisce i file nella staging area
• il comando git commit  salva la nuova versione nel Repository

Ricordatevi molto bene questo meccanismo perchè vi sarà utile quando eseguirete i comandi o quando dovrete fare azioni potenzialmente distruttive, come recuperare file da vecchie versioni.

I comandi base di GIT: inizializzare il Repository

Se avete già un progetto, ad esempio nella cartella C:\project, il primo passo da fare è accedere alla GIT BASH e posizionarvi nella cartella del progetto per inizializzare il repository

cd C:\project
git init

questo creerà la cartella C:\project\.git che contiene un Repository vuoto.

Per aggiungere i files (e le sottocartelle) alla Staging Area, usate il comando

git add .

il punto serve a dirgli di includere tutto, altrimenti dovrete specificare dopo “git add” tutti i files che intendete inserire nel Repository.

Per salvare la vostra prima versione nel Repository dovete committare (indicando un messaggio che vi sarà utile in futuro per capire cosa contiene quella versione)

git commit -m "start project"

E’ possibile anche taggare la versione con

git tag -a v1.0 -m "version 1.0"

I comandi base di GIT: modificare i files e creare nuove versioni

Ipotizziamo ora di modificare un file all’interno della cartella C:\project, potete farlo in vari modi: se è un file testuale potete usare vim (l’editor presente in GIT) oppure modificarlo esternamente:

vim readme.txt

Se lanciate git status, ora GIT vi avvertirà che il file è stato modificato ma non è ancora stato aggiunto alla staging area (quindi non è committabile)

git status

On branch master
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)

 modified: readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

Per salvare questa versione bisogna aggiungere il file modificato alla staging area con git add .  oppure semplicemente:

git commit -a -m "modificato file readme.txt"

[master 34ac2] modificato file readme.txt
1 file changed, 1 insertion(+)

git commit -a aggiunge automaticamente tutto alla staging area e committa in 1 unica istruzione.

Per essere sicuri che sia stato committato tutto bisogna verificare che git status git status  restituisca il seguente messaggio:

git status

On branch master
nothing to commit, working directory clean

I comandi base di GIT: le differenze di versione

Per vedere cosa è stato modificato potete usare il comando git diff (esistono diverse varianti) oppure lanciare

gitk  che vi mostra le differenze da interfaccia grafica.

Per visualizzare la storia esistono diversi comandi:

git log
git log --stat

Per avere un elenco riepilogativo delle versioni committate:

git log --graph --oneline --decorate --all

* 34ac2 (HEAD -> master) modificato file readme.txt
* 98ca9 (tag: v1.0) start project

A fianco di ogni commit viene mostrato l’hash (esempio 34ac2). L’hash è un codice random di 32 caratteri che identifica univocamente la versione, ma solitamente i primi 5-7 caratteri bastano per identificarlo e possono essere utilizzati in tutti i comandi che lo richiedono.

Ad esempio, se per sbaglio avete perso (o modificato) un file e volete recuperarlo da una vecchia versione, il comando è git checkout hash path/file

git checkout 98ca9 readme.txt

questo sovrascriverà il file readme.txt nella tua working directory con quello presente nella prima versione 98ca9 (start project).

Creare un ramo alternativo (fork)

GIT incoraggia a creare rami (branch) che deviano dalla versione principale master.
I branch, nella programmazione, consentono di lavorare su feature alternative o sulla risoluzione di bug. Una volta completato il lavoro su un branch è possibile poi unirlo (merge) al ramo principale master. Ogni utente che lavora su un progetto può creare suoi rami e poi proporli per essere inseriti nella versione ufficiale.

GIT ha funzioni avanzate per la gestione dei rami, qui vedremo il caso più semplice.

Creiamo un nuovo ramo chiamato testing

git branch testing

per spostarsi a lavorare su questo ramo

git checkout testing

Ora esistono 2 branch, il primo (master) quello ufficiale e il secondo (testing) che puntano alla stessa versione di commit f30ab.

HEAD è semplicemente un puntatore che indica su quale ramo si sta lavorando.

La GIT BASH segnala infatti che si sta lavorando sul branch testing (e non più master)

Bacon@BACON ~/project (testing)

Ipotizzando di committare una nuova versione la situazione sarà la seguente:

git commit -a -m 'nuova modifica'

[testing 87ab2] nuova modifica
1 file changed, 1 insertion(+)

Ora testing punta al nuovo commit 87ab2, mentre master punta ancora al vecchio.

Ipotizziamo ora che la versione testing ci sembra stabile e vogliamo unire queste modifiche alla versione ufficiale master (eliminando il branch testing che ora non ci serve più):

git checkout master
git merge testing
git branch -d testing

Se non vengono individuati conflitti tra le 2 versioni, master punta ora alla nuova versione 87ab2.

Come evitare di perdere tutto e come usare Repository remoti

Avere una sola copia del progetto sul proprio PC non è l’ideale, soprattutto se si rompe l’hard-disk e si perde tutto il suo contenuto. Inoltre se più persone devono lavorare sul progetto è indispensabile avere un meccanismo per poter condividere il lavoro, cioè committare le proprie versioni su un server e scaricare le versioni committate da altri.

Il modo migliore per fare questo è avere un server che ospita il Repository al quale tutti possono collegarsi.

Esistono diversi Servizi Online che offrono la possibilità di ospitare repository gratuitamente o pagando una piccola quota.  Qui trovi un elenco esaustivo che mette a confronto i vari servizi:

• GitHub è sicuramente la soluzione migliore se si lavora su progetti open source, poichè gratuito. Per progetti commerciali invece è a pagamento.
• BitBucket è invece la scelta migliore per piccoli progetti commerciali, poichè gratuito fino a 5 persone che lavorano contemporaneamente al progetto. Se le persone sono più di 5 si paga una quota proporzionale al numero di persone che lavorano sul progetto.

I comandi da utilizzare con un server sono semplicissimi:

• clonare un progetto da GitHub sul proprio pc, esempio git clone https://github.com/libgit2/libgit2 mylibgit
• committare le proprie versioni sul server con git push -u origin master
• aggiornare il Repository locale con quello presente sul server, esempio git pull origin master

In alternativa è possibile configurare un proprio server per ospitare il Repository, in uno dei prossimi articoli vedremo come fare.