Controllo di versione e Git

Version Control
Introduzione, principi generali e implementazione in Git
gennaio 2011
aggiornato aprile 2012
ri-aggiornato febbraio 2013
ri-ri-aggiornato aprile 2014

Di che si parla?
● Quando un progetto software diventa complesso,
anche la sua gestione è complicata
● Il controllo revisioni permette di gestire tutte le
modifiche apportate ai documenti del progetto,
archiviando tutte le versioni del progetto sin dal suo
inizio
● Ecco cosa si può fare...

E se non lo uso?
● E' un mondo libero, e ciascuno è libero di sbagliare
nel modo che preferisce.
● MA questo è quello che può succedere..

Metodologie di sviluppo...
● Sviluppatore singolo
● Più sviluppatori
– Sviluppo con copie multiple
– Sviluppo con copia unica

Sviluppatore singolo
#include<stdio.h>
Int main()
{
int a;
int b;
}
File.c
#include<stdio.h>
Int main()
{
int a;
}
File.c
Ieri
Oggi

(Problemi)
● Difficile recuperare le versioni più vecchie
basandosi sulla data.
● Difficile stabilire le differenze tra le versioni di uno
stesso file.

Sviluppatori multipli
(Sviluppo con copia individuale)
Sviluppatore-1
Sviluppatore-2
Sviluppatore-3
PC-1
PC-2
PC-3
server

(Sviluppo con copia individuale)
Problemi
● Difficile riunire i vari file modificati singolarmente.
● Difficile recuperare le versioni precedenti basandosi
sull'utente o sulla data.

(Sviluppo con copia unica)
Sviluppatore-1
Sviluppatore-2
Sviluppatore-3
server

(Sviluppo con copia unica)
Problemi
● Impatto sul server e traffico di rete.
● Tempi di sviluppo lenti.
● Difficile recuperare le versioni precedenti,
basanndosi sulla data o sull'utente.
● Non si possono vedere le differenze tra la versione
precedente e l'attuale.

I problemi in sintesi
● Non c'è modo di recuperare le versioni precedenti,
basandosi sulla data o l'utente.
● Non c'è modo di vedere le differenze tra le versioni.
● Processo di fusione versioni manuale, lento e di
dubbio successo.
● Lunghi tempi di sviluppo.

Come risolverli?
● Utilizzando, ad esempio, un sistema di controllo
revisione.
● Detto anche Versioning, o Revision Control System
● Revision control (also known as version control, source control
or (source) code management (SCM)) is the management of
changes to documents, programs, and other information stored
as computer files.

#include<stdio.h>
Int main()
{
int a;
int b;
}
File.c
#include<stdio.h>
Int main()
{
int a;
}
File.c
Ieri
Stamattina
Versione-1 Versione-2 Versione-3
#include<stdio.h>
Int main()
{
int a;
int b;
}
File.c
Stasera

(Sviluppo in copia individuale)
Sviluppatore-1
Sviluppatore-2
Sviluppatore-3
Copia di lavoro - 1 del
Repository
Server
Repository (deposito)
principale
Copia di lavoro - 2 del
Repository
Commit (Consegna)
Primo checkout (copia) dal repository del server
Aggiornamentodal server
Copia di lavoro – 3 del
Repository

Gestione file nel Repository
Versione-1
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-2
Date : 24-10- 2007
Time :11:00:12
User : user-2
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-3
Date : 24-10- 2007
Time :1200:12
User : user-3
Date : 24-10- 2007
Time :1200:12
User : user-2
Date : 24-10- 2007
Time :12:00:12
User : user-2
Date : 24-10- 2007
Time :12:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-2
Date : 24-10- 2007
Time :11:00:12
User : user-2
Date : 24-10- 2007
Time :11:00:12
User : user-3
Date : 24-10- 2007
Time :11:00:12
User : user-3
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-1
Date : 24-10- 2007
Time :11:00:12
User : user-2
Date : 24-10- 2007
Time :11:00:12
User : user-2
Date : 24-10- 2007
Time :11:00:12
User : user-3
Date : 24-10- 2007
Time :11:00:12
User : user-3
Date : 24-10- 2007
Time :11:00:12
Versione-2 Versione-3 Versione-4

Cosa otteniamo?
Un posto dove memorizzare le varie versioni
del codice (e tutti i documenti correlati)
Possibilità di “tornare indietro” in caso di errore
e tracciare le modifiche
Codice sempre aggiornato
Sviluppo parallelo facilitato

40 anni di versioning
SCCS & RCS ('70) CVS (2006)
Subversion (2001) GIT (2005)

SCCS e RCS
● SCSS: Rilasciato nel 1972, proprietario
● Enorme successo
● Base di tutti gli altri sistemi
● RCS: Rilasciato nel 1983, free software
● Lavora solo su singoli file
● Sintassi complessa

CVS
● Basato su (RCS) con informazioni addizionali
● Presenta però alcune lacune, tra le quali:
– Supporta solo file di testo
– Numerazione separata per ogni file
– Impossibile rinominare i file

SVN
● Subversion, SVN per gli amici, è un'evoluzione di
CVS
– E' open source e gratuito (Apache Licence)
– E' molto diffuso
– E' multipiattaforma
– E' integrato in vari IDE

DRCS: Hg e Git
● Con l'avvento di Internet, si sviluppano i Distributed
Revision Control System.
● Sfruttano le nuove caratteristiche dei sistemi e la
rete.
● I più noti sono Mercurial (Hg per gli amici) e Git.
Basati su un software proprietario chiamato
Bitkeeper
● (ma sono entrambi open source)

DRCS – perché è meglio?
Git SVN
Si può lavorare offline, perché il sistema è
locale
Se non c'è rete non si può lavorare (e si
piange amaramente)
Si può portare il lavoro in una chiavetta No, non si può
Creazione semplice di una diramazione
sperimentale
Creare diramazioni è complicato
Setup semplice Occorre installare o appoggiarsi a un server
Non c'è un deposito centrale e di riferimento
(anche se ci si può accordare). Tutti hanno
la copia di tutto.
Il server centrare contiene tutte la modifiche.
Il download iniziale potrebbe essere di
grandi dimensioni

Glossario
● Repository (deposito)
Un insieme di oggetti (file) e i riferimenti necessari.
Può essere online o offline
● Clone (solo git)
L'atto di duplicare localmente un repository
● Commit (lett. 'impegno', ma qui 'consegna')
Invio delle modifiche effettuate al repository
● Checkout
Copia o ripristino di una particolare versione del
progetto

GIT – il funzionamento
● GIT identifica tre possibili 'stati' per ogni file del
progetto a cui si sta lavorando
● Working Copy
Sono i file a cui state lavorando, che potete
modificare liberamente
● Staging Area
I file che avete modificato e che avete intenzione di
“committare” nel progetto definitivo
● Commit
I file modificati

Un esempio più pratico
● Vedremo il sistema applicato alla pratica
● Non useremo un programma, dato che
funziona per tutti i tipi di file (al meglio con i file
di testo)
● Si presume che abbiate già installato Git (ne
parleremo separatamente)

Pentitevi,
infedeli!!
Pentitevi,
infedeli!!

$ mkdir librosacro
$ cd librosacro
$ git init

Capitolo 1
NerdGenesi
All'inizio ci fu Bob, che
era l'origine di tutto.
'capitolo 1.txt' salvato

$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#
(use "git add <file>..." to
include in what will be committed)
#
#
chapter1.txt

$ git add chapter1.txt
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#
(use "git rm cached <file>..."
to unstage)
#
# new file: chapter1.txt

$ git commit m
“Aggiungi il primo capitolo.”
[master (rootcommit) 8621aee]
Aggiungi il primo capitolo.
1 files changed, 1 insertions(+), 0
deletions()
create mode 100644 chapter1.txt

Whew!
● Diamo un'occhiata al log per vedere cos'è successo.
● $ git log
commit
bb9c52540ec20eca6bb3aee5713fb24474959b6a
Author: Marcello Missiroli
<prof.missiroli@gmail.com>
Date: Sun Jan 27 18:09:15 2013 +0100
Reservations: start
Indice del “commit”.
Calcolato in base al nome
dell'autore, alle modiche
e alla data.
Commento

E più in dettaglio...
● git diff HEAD
app/views/users/index.html.haml
@@ -3,14 +3,15 @@
-%ul{:class=>"users"}
-@users.each do |user|
+%table{class: "table table-striped"}
+ %tr
+ %th{:class => @name_header}= link_to 'Nome'

Ciao, sono
Tim
Ciao, sono
TimInsieme scriveremo...Insieme scriveremo...
Il Librone sacro!

$ git remote add origin
git://librone/sacro.git
$ git push origin master
Protocolli utilizzabili:
Git, ssh. http, local.

$ git clone
git://librone/sacro.git
$ cd librosacro

Capitolo 2
NerdCloning
E poi ci fu Tim, che
pensava che era cosa buona
E giusta.
'capitolo 2.txt' salvato

$ git add 'capitolo 2.txt'
$ git commit m “Secondo capitolo'
$ git push origin master
$ git pull origin master
$ ls
capitolo 1.txt capitolo 2.txt

$ git commit m 'Terzo capitolo'
$ git commit m 'Capitolo bello'
$ git commit m 'Capitolo nuovo'
$ git commit m 'Quarto capitolo'
$ git commit m 'Nuove idee'
$ git commit m 'Conquista'

Branching – merging - conflitti
● Finora tutte le modifiche confluiscono in un unico
prodotto finale
● Può essere necessario lavorare su versioni separate
dei file per evitare di “sporcare” il lavoro degli altri
(o per altri motivi)
● E' opportuno creare dei branch (diramazioni) sulle
quali lavorare in piena libertà

Branching – merging - conflitti
● Il modo consigliato di lavoro è proprio questo:
1) Branch & Edit
Lavorate su una versione separata del codice
2) Merge
Risincronizzarsi col ramo principale e risolvere
conflitti
3) Commit
Inviare le modifiche al repository centrale

$ git b comandamenti
$ git branch
master
* comandamenti

$ git checkout b comandamenti
$ git add comandamenti.txt
$ git commit m “Inizio
comandamenti.”
$ ls
capitolo 1.txt
capitolo 2.txt
comandamenti.txt
$ git checkout master
$ ls
capitolo 1.txt
capitolo 2.txt

$ git checkout comandamenti
$ git commit m “Primo
comandamento”
$ git commit m “Secondo
comandamento”
$ git merge commandments

master
mastermaster
comandamenti
master

master
mastermaster
comandamenti
masterprecetti

Le branch sono utili
...ma possono diventare
complicate da gestire!

$ git pull origin master
$ git merge comandamenti
Automerging Capitolo 1.txt
CONFLICT (content):
Merge conflict in Capitolo 1.txt
Automatic merge failed;
fix conflicts and then
commit the result.

$ <<<<<<< HEAD:Capitolo 1.txt
All'inizio ci fu Bob, che
=======
All'inizio ci fu Tim, che
>>>>>>> comandamenti:Capitolo 1.txt
Commit? Discard?Commit!

$ git remote add libroditim
git://libroditim/librone.git
$ git push libroditim master

* Installazione
* GitHub
* Demo project
Next: Workshop

GIT – Altri Links
● Netbeans:
– http://www.netbeans.org
● GIT:
– Repository pubblici online
https://github.com/
https://bitbucket.org/
– codeschool:
http://try.github.com/levels/1/challenges/1
– The Git Book
http://git-scm.com/book

Grazie
● Con il contributo di
●
Anil GuptaAnil Gupta (www.guptaanil.com)
● Pete Nicholls (github.com/Aupajo)
● Armando Fox
Questo documento è dotato di licenza CreativeCommonQuesto documento è dotato di licenza CreativeCommon
BY-SA 3.0BY-SA 3.0
●
http://creativecommons.org/licenses/by-sa/3.0/deed.ithttp://creativecommons.org/licenses/by-sa/3.0/deed.it

Controllo di versione e Git

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Controllo di versione e Git (20)

More from Marcello Missiroli (13)

Controllo di versione e Git