Introduzione al Controllo di versione (in generale) e al funzionamento di Git (in particolare). Upgrade di un'altra presentazione simile nelle basi ma incentrata su SVN.

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

2. 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...

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

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

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

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

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

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

9. Sviluppatori multipli
(Sviluppo con copia unica)
Sviluppatore-1
Sviluppatore-2
Sviluppatore-3
server

10. Sviluppatori multipli
(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.

11. 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.

12. 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.

13. Sviluppatore singolo
#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

14. Sviluppatori multipli
(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

15. 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

16. 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

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

18. 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

19. 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

20. 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

21. 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)

22. 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

23. 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

24. 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

33. 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)

34. Ciao, sono
Bob
Ciao, sono
Bob

36. Pentitevi,
infedeli!!
Pentitevi,
infedeli!!

37. $ mkdir librosacro
$ cd librosacro
$ git init

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

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

40. $ 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

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

42. 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

43. 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'

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

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

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

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

48. $ 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

49. $ 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'

50. 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à

51. 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

52. $ git ­b comandamenti
$ git branch
master
* comandamenti

53. $ 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

54. $ git checkout comandamenti
$ git commit ­m “Primo
comandamento”
$ git commit ­m “Secondo
comandamento”
$ git checkout master
$ git merge commandments

55. master
mastermaster
comandamenti
master

56. master
mastermaster
comandamenti
masterprecetti

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

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

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

60. Fork!

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

62. * Installazione
* GitHub
* Demo project
Next: Workshop

63. 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

64. 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