Git: un'introduzione pratica

Git: gestione comoda del repository
di Roberto Polli

Version Control System
Quando si sviluppa un software, è necessario tenere traccia dei cambiamenti tra una
versione e l’altra. Per questo si usano dei software chiamati Version Control System (VCS). Il
ciclo di funzionamento base di questi programmi è il seguente:
1. si inizializza la directory contenente i sorgenti del software - detta repository;
2. si scrive o modifica il software;
3. si esegue il commit, ossia si archivia sul VCS lo stato attuale.

Un VCS quindi permette di ripristinare una versione precedente del software, o di mostrare
le differenze tra due versioni differenti.

Git
Git è un VCS di “nuova” generazione, utilizzato tra l’altro per la manutenzione dei sorgenti di
Linux. I suoi predecessori sono CVS e Subversion - ancora molto usati. La differenza
sostanziale tra il “vecchio” e il “nuovo” è l’approccio distribuito di git rispetto a quello
centralizzato di svn.
Chi fosse interessato alla cosa può vedere la voce Distributed Revision Control di Wikipedia.

Invece di approfondire le caratteristiche generali di un VCS e altre interessanti approcci
teorici, affronteremo dei casi pratici in cui git può facilitarci la vita quotidiana.

Tracciare i cambiamenti di una configurazione locale
Spesso è utile tracciare i cambiamenti dei file di configurazione. Una scelta classica è quella
di rinominare i file con dei suffissi. Il comando #cp ci viene incontro con la variabile
SIMPLE_BACKUP_SUFFIX. E’ possibile backuppare il file /etc/hosts in tutti questi modi:

#cp /etc/hosts /etc/hosts.ori
#cp /etc/hosts{,2011-09-18}
#cp -bfS”-$(date -I)” /etc/hosts /etc/hosts

BABEL S.r.l. - P.zza S.Benedetto da Norcia 33 - 00040, Pomezia (RM) - Tel:. +39 06.9826.9600 - Fax. +39 06.9826.9680
E-Mail: info@babel.it – PEC: babel@pec.babel.it – WEB: http://www.babel.it
Reg. Imprese di Roma N° 06062681009 - N.R.E.A. 953123 - P.I. e C.F. 06062681009 Cap. Soc. € 102.774,00 i.v.
Società soggetta alla direzione e coordinamento della Par-tec S.p.A - Società iscritta al registro delle Imprese di Milano al numero
1293820015

Il comando #cp permette di specificare un suffisso impostando la variabile
SIMPLE_BACKUP_SUFFIX.

#export SIMPLE_BACKUP_SUFFIX=”-$(date -I)”
#cp -bf /etc/hosts /etc/hosts

Esercizio: utilizzare il comando #date +%s; per creare un timestamp con
SIMPLE_BACKUP_SUFFIX. Notate qualcosa di strano? E’ possibile ottenere il comportamento
attesa da SIMPLE_BACKUP_SUFFIX utilizzando la built-in #alias di bash: come?

Dopo alcuni cambiamenti, ci troveremo con la directory piena di file:

#ls /etc/hosts*
/etc/hosts /etc/hosts-2011-09-11 /etc/hosts-2011-09-08 /etc/hosts-2011-08-01
/etc/hosts-2010-12-11

Vediamo come ottenere lo stesso risultato con git: innanzitutto creiamo un repository nella
directory /etc:

#git init /etc/
Initialized empty git repository in /etc/.git/

Quindi “prenotiamo” l’archiviazione del file hosts, infine aggiungiamolo all’archivio indicando
con -m un messaggio che spieghi le modifiche fatte: questo è molto importante per
recuperare le versioni precedenti dei file!

#git add /etc/hosts # add hosts to the controlled files
#git commit -m “take a snapshot of current hosts file”

Ora se aggiungiamo una nuova linea al file, possiamo usare git per vedere le modifiche che
abbiamo fatto.

# echo “127.0.0.1 localhost.localdomain” | sudo tee -a /etc/hosts
# git diff hosts

1293820015

diff --git a/hosts b/hosts
index bfa5424..90132af 100644
--- a/hosts
+++ b/hosts
@@ -1 +1,2 @@
10.0.0.1 ananke
+127.0.0.1 localhost.localdomain

Se le modifiche ci piacciono, possiamo anche aggiungerle al repository.
Attenzione! A differenza di altri VCS, come Subversion, dobbiamo aggiungere nuovamente
il file al repository:

#git add /etc/hosts
#git commit -m “aggiunto localhost.localdomain”

Per imitare il comportamento di svn, possiamo usare una scorciatoia. Il parametro “-a” di
#git commit; aggiungerà al commit tutti i file precedentemente aggiunti.

#git commit -a -m “aggiunto localhost.localdomain”

A questo punto possiamo non solo verificare tutte le modifiche fatte al nostro file, ma anche
tracciare un log:

#git log
commit 5042b20d0bccc382b2c0f3ce99a25020b681e3d9
Author: Roberto Polli <rpolli@babel.it>
Date: Sun Sep 18 17:26:03 2011 +0200

aggiunto localhost.localdomain

commit 819147de036ea16122cea34dfac3db5c2e4f0176
Author: Roberto Polli <rpolli@babel.it>
Date: Sun Sep 18 17:17:33 2011 +0200

take a snapshot of current hosts file

1293820015

Questo log contiene non solo i dati salienti delle modifiche (messaggio e autore) ma anche
un identificativo del commit, ottenuto tramite un hash di tipo sha1. Chi viene da svn - che
utilizza un numero intero progressivo per individuare le versioni - potrà reputare il sistema
un po’ scomodo.

Per ripristinare una vecchia versione della directory però, basta usare le prime cifre
del’hash. In mancanza di altre corrispondenze, git individuerà il commit giusto.

#git checkout 81914 -- hosts

o tornare ad utilizzare l’ultima versione

#git checkout master -- hosts

Master
Il “master” è il ramo principale di sviluppo. Contiene solitamente l’ultima versione del
software. Nei paragrafi successivi vedremo come sia possibile creare altri rami di sviluppo -
contenenti versioni diverse dei files: i branch. Formalmente il master è un branch a tutti gli
effetti. È semplicemente quello di default.

Bignamino
Creare un repository: #git init /path
Schedulare un file per l'aggiunta al repository: #git add /path/file.txt
Archiviare una modifica: #git commit -m “changelog message”
Archiviare le modifiche dei file già presenti nel repository: #git commit -a -m “changelog
message”
Differenze tra la working-copy e l'ultimo commit: #git diff /path/file.txt
Mostra il log delle modifiche di un file: #git log /path/file.txt
Checkout della revision di un file: #git checkout REV -- file.txt
Checkout dell'ultimo commit di un file: #git checkout master -- file.txt

1293820015

Git e l’utilità dei branch
Dopo aver imparato il funzionamento base di git, proviamo ad inserirlo in un progetto di
sviluppo. La prima cosa da fare è creare un repository ed aggiungerci i nostri file iniziali:

#cd workspace/samplephp
# git init .
# git add *.php js/
# git commit -m “import iniziale del progetto”

A questo punto, anziché iniziare a sviluppare creiamo subito una copia del progetto, che git
chiama branch: lavoreremo su quella ed effettueremo il commit sul ramo solamente alla
fine. Come nome del branch utilizzeremo il task che ci prefiggiamo di compiere: in modo da
non dimenticare mai il focus della nostra attività.

#git branch editcss master

Ora passiamo a lavorare sul branch, e aggiungiamo o modifichiamo i file che ci interessano:

#git checkout editcss
#mkdir css/; vi style.css;

Infine aggiungiamo e committiamo:

#git add css/*
#git commit -m “aggiunto css”

Non lavorando sul master, possiamo committare quante volte vogliamo: anche per tenere
una nostra history locale e tracciare le modifiche senza ritrovarci il ramo di sviluppo pieno di
file duplicati.

#git commit -a -m “facciamo un paio di prove con questa modifica”
...
#git commit -a -m “facciamo un paio di prove ora con questa nuova modifica”
…

1293820015

E vediamo quindi le differenze tra due modifiche intermedie:

#git diff 0e2dc5df 208dc5ef6d
diff --git a/newfeature.php b/newfeature.php
new file mode 100644
index 0000000..e69de29

..oppure tra una delle vecchie modifiche e la working copy:

#git diff 0e2dc5df

Finite le modifiche sul branch posso fare il merge sul master tree. Ritorno quindi al ramo
principale facendo:

#git checkout master

Quindi lancio il merge, che in questo caso sarà semplice, poiché il master non ha subito
modifiche.

#git merge editcss

In caso di conflitti, è possibile gestirli similmente ad altri vcs tipo svn: verrà creato un file
con gli indicatori di conflitto.

<<<master
changeset
========
theirs
>>>branch

Il file in questione andrà quindi modificato con un editor, risolvendo il conflitto

#vim /path/conflicted.txt

Anziché utilizzare un editor, è possibile risolvere il conflitto utilizzando anche il comando:

1293820015

#git mergetool

di cui trovate la documentazione digitando

#git help mergetool

Risolto il conflitto, il file poi andrà marcato come risolto col comando

#git add /path/conflicted.txt

Quindi sarà possibile fare nuovamente il commit

#git commit -m “merge di newfeature”

Repository remoti
Chi usa svn avrà notato subito che la terminologia è un po’ diversa rispetto a git. Il checkout
infatti non indica il “download” dei file dal repository, ma il cambiamento della versione di
lavoro. Per caricare i file da remoto infatti git usa il comando clone.

Per scaricare da Sourceforge ad esempio l’ultimo progetto open source di Babel, un policy
delegator per Postfix, si lancia:

#git clone git://git.code.sf.net/p/bamp/code bamp-code
Initialized empty git repository in /tmp/bamp-code/.git/
remote: Counting objects: 87, done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 87 (delta 20), reused 0 (delta 0)
Receiving objects: 100% (87/87), 174.95 KiB | 79 KiB/s, done.
Resolving deltas: 100% (20/20), done.

Origin
Questo scaricherà tutto il repository nella cartella bamp-code. Da questo momento in poi
avremo - in locale - una copia esatta del repository.

1293820015

La differenza tra la copia e l’originale è contenuta nella configurazione di git.

#git config -l
color.ui=auto
user.email=rpolli@babel.it
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=git://git.code.sf.net/p/bamp/code
branch.master.remote=origin
branch.master.merge=refs/heads/master

Il parametro remote.origin.url ci dice che il repository remoto è
git://git.code.sf.net/p/bamp/code

Potremo quindi modificare il nostro software ed anche effettuare dei commit locali senza
toccare il repository remoto.

Per inviare poi i cambiamenti sull’origin, dovremo sincerarci di avere il ramo aggiornato,
eseguendo:

#git pull origin

Quindi effettuare il push sull’origin delle nostre modifiche:

#git push origin

E’ possibile inoltre switchare l’origin in maniera semplice, ed effettuare il pull di un nuovo
progetto da un altro repository.

Creiamo un nuovo repository in /etco:

#git init /tmp/etco

1293820015

#cd etco; touch ./newfeature.php;
#git add newfeature.php
#git commit -m “nuovo file dal nuovo repository”

Ed ora modifichiamo l’url del repository remoto, per scaricare la nuova versione di
newfeature.php:

#git config remote.origin.url ssh://localhost/tmp/etco/

Il pull ci farà notare che c’è un file in conflitto, che necessita un merge.

#git pull
rpolli@localhost's password:
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ssh://localhost/tmp/etco
* branch HEAD -> FETCH_HEAD
Auto-merging newfeature.php
CONFLICT (add/add): Merge conflict in newfeature.php
Automatic merge failed; fix conflicts and then commit the result.

A questo punto, risolviamo il conflitto modificando il file con un potente IDE per il web:

# vi newfeature.php

quindi committiamo (ricordandoci di aggiungere il file a quelli da committare):

# git add newfeature.php; git commit -m “risolto il conflitto di
newfeature.php”

Ed è questa una delle particolarità di git: la capacità di gestire diverse versioni di un
progetto in maniera semplice, tenendo sempre traccia di tutto.

1293820015

Un semplice caso di troubleshooting
Proviamo ora ad usare git per uno scopo un po’ meno ortodosso: sarà l’occasione per
conoscere meglio il nostro nuovo strumento di lavoro.

Vogliamo usare git per pubblicare gli aggiornamenti su un webserver - con indirizzo
antani.babel.it. La directory è /var/www/mysite/.

Rendiamo il nostro sito un repository git.

antani# cd /var/www/mysite;
antani# git init .
antani# git add .
antani# git commit -m “first import”

Creiamo una copia locale del repository sul nostro PC:

localhost# git clone ssh://antani.babel.it/var/www/mysite .

e modifichiamo i file utilizzando la procedura prima descritta:

localhost# git checkout -b editcss
localhost# git add css/*
localhost# git commit -m “added css”

quindi effettuiamo il merge sul nostro master:

localhost# git checkout master
localhost# git merge editcss
Updating 3ca4018..6080e12
Fast-forward
css/ | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

A questo punto per pubblicare le nostre modifiche dovrebbe bastarci fare un push sull’origin
per vedere pubblicate sul nostro webserver le nostre modifiche. Lanciamo quindi:

1293820015

localhost# git push origin
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 275 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare
repository
remote: error: is denied, because it will make the index and work tree
inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to
match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable
to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing
into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in
some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour,
set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://antani/var/www/mysite/
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://antani/var/www/mysite/

Niente paura! Git ci sta dicendo qualcosa di molto semplice. Non è possibile fare il push su
un branch attivo. Potrebbero infatti esserci modifiche locali non committate in
antani:/var/www/mysite/. Tali modifiche andrebbero perse nel caso di push.
1293820015

Tale commit sarebbe andato a buon fine invece se la directory di destinazione fosse stata un
“bare repository”. Un “bare repository” è - come dice la parola stessa - un repository nudo e
crudo, senza working copy per dirla a-la-svn. Un archivio dei file, coi master e branches, ma
senza nessun file attivo da poter modificare. Su di esso possiamo fare solamente clone e i
push.

Non è questo però il nostro caso: noi vogliamo che nella directory /var/www/mysite i file ci
siano e che vengano serviti! La soluzione è semplice, e consta di due passaggi:
1. dobbiamo dire a git che i file nel branch master/ non verranno modificati nella
working-copy;
2. a modifica effettuata dobbiamo effettuare nuovamente il checkout del branch
master.

Vediamo la nostra strategia all’opera quindi:

antani# cd /var/www/mysite

creiamo il branch dummy

antani# git checkout -b dummy
antani# git branch -a
* dummy
master

Ora torniamo sul nostro PC ed effettuiamo il push verso il master: ora fila tutto liscio, e
l’origin è aggiornato.

localhost#git push origin
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 275 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)

1293820015

To ssh://localhost/var/www/mysite
3ca4018..6080e12 master -> master

Tornando nuovamente sull’origin, i file che troviamo sono ancora quelli vecchi:

antani# ls /var/www/mysite/

ma effettuando il checkout verso il master vediamo che tutto invece è aggiornato:

antani# git checkout master

e che sul master troviamo tutti i file che ci aspettavamo!

Quest’ultimo paragrafo - che non propone una metodologia di lavoro, ma vuole
semplicemente esplorare alcuni casi limite di utilizzo di git - mostra come la dimensione di
“gioco” e sperimentazione porti ad approfondire la conoscenza degli strumenti di lavoro.
Non fatevi scrupoli quindi a sperimentare e ad usare i software (non in produzione eh!)
anche in maniera impropria o fantasiosa, imparerete sicuramente qualcosa!

1293820015

Licenza d'uso “Attribuzione - Non commerciale - Non opere derivate”, secondo i criteri
internazionali Creative Commons (http://creativecommons.org/licenses/by-nc-nd/2.5/it/)

1293820015

Git: un'introduzione pratica

More Related Content

Similar to Git: un'introduzione pratica (20)

More from Babel (20)

Git: un'introduzione pratica