Git: sistema di versionamento distribuito - Igor Maculan Andrea Vanzan Padova, 18/02/2016 - InfoCamere
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Git: sistema di versionamento distribuito
Igor Maculan
Andrea Vanzan
Padova, 18/02/2016
IC-GEN-Presentazione-160128
Sommario
• Versionare
• Git, i concetti di base
• EGIT: Eclipse + Git
• Best practices
1
Versionare
Cosa vuol dire?
Il controllo di versione è un sistema che registra, nel tempo, i cambiamenti ad un file o ad
una serie di file, così da poter richiamare una specifica versione in un secondo momento.
Molte persone gestiscono le diverse versioni copiando i file in un'altra directory (magari una
directory denominata con la data). Questo approccio è molto comune perché è molto
semplice, ma è anche incredibilmente soggetto ad errori. É facile dimenticare in quale
directory sei e modificare il file sbagliato o copiare dei file che non intendevi copiare.
2
Versionare
Version Control System (VCS)
Funzionalità
• Ripristinare i file ad una versione precedente
• Ripristinare l'intero progetto a uno stato precedente
• Revisionare le modifiche fatte nel tempo
• Vedere chi ha cambiato qualcosa che può aver causato un problema
• Creare dei “rami”(branch) alternativi dove implementare/sperimentare nuove
funzionalità senza doversi preoccupare di “sporcare” il codice esistente
• Condividere il progetto tra più sviluppatori
• Poter risalire ai sorgenti di una determinata versione del prodotto
3
Versionare
VCS Centralizzato (CVCS)
• Unico server centrale
• Nessun versionamento locale
• Connessione al server obbligatoria
Esempi
• CVS
• SVN
4
Versionare
VCS Distribuito (DVCS)
• Non necessita di un server centrale
• Permette un versionamento locale
• Non necessita di una connessione
• Permette di sincronizzare i progetti da uno
sviluppatore ad un altro
• Possibilita’ di lavorare con server multipli
(es: server di gruppi diversi)
Esempi
• GIT
• Mercurial
5
Git
Git o SVN?
“Git is not better than Subversion. But is also not worse. It's different.”
[Pro]
• Decentralizzato
• Orientato ai branch
• Buon sistema di merging
• Largamente utilizzato
• Performante
• Backup implicito distribuito dell’intero repository
• Tag locali
• Granularità di permessi
[Contro]
• Complesso
• Impossibilità di clonare sotto directory
• Versionamento non progressivo (SHA1)
• Tag su singolo commit
• Commit su singolo branch
6
Git
Chi lo usa?
7
Git
Il repository locale
Quasi tutte le operazioni che si effettuano su GIT sono locali, quindi non necessitano di una
connessione o di un server centrale per funzionare.
L’intera storia del progetto e’ interamente in locale, all’interno della directory .git
Le uniche operazioni che si svolgono “online” sono di sincronizzazione tra i repository, quindi tra
le directory .git che risiedono nella workstation ed in un server/sviluppatore remoto
Per chi e’ abituato ad un sistema centralizzato (CVS,SVN) e’ come avere un server centrale nella
propria workstation e, mediante dei comandi dedicati, sincronizzare i vari server/sviluppatori in
rete
8
Git
Tre stati
La directory di Git è dove Git salva i metadati e
WorkStation il database degli oggetti del tuo progetto. Questa
è la parte più importante di Git, ed è ciò che
viene copiato quando si clona un repository da
un altro computer.
La directory di lavoro è un checkout di una
versione specifica del progetto. Questi file
vengono estratti dal database compresso nella
directory di Git, e salvati sul disco per essere
usati o modificati.
L'area di stage è un file, contenuto
generalmente nella directory di Git, con tutte le
informazioni riguardanti la tua prossima commit.
A volte viene indicato anche come 'indice', ma lo
standard è definirlo come 'area di stage'
9Git
Workflow
1. Modifica i file nella tua directory di lavoro
2. Fanne lo stage, aggiungendone le istantanee all'area di stage
3. ”Committa”: salva i file dell'area di stage in un'istantanea (snapshot) permanente
nella tua directory di Git.
4. “Pusha”: allinea il/i server/sviluppatori remoti
5. “Pulla”(Fetch+Checkout): allineati alle modifiche dei server remoti
Workstation User2
Workstation User1 Working Dir
Working Dir
Stage Area
Add/Remove .git Dir
Stage Area
Fetch Push
Checkout/Reset Commit
Remote Server
Push
.git Dir Fetch .git Dir
10Git
Utilizzo classico: Sviluppatore – Server Centrale
11Git
Modello GitHub
Utilizzato tipicamente per progetti opensource, dove il numero di contributors varia ed ognuno può
creare una propria «versione» del sorgente
GitHub server
Repository
fork Dev1 Repo push/pull Dev1
principale
Dev2 Repo push/pull Dev2
pull request
Integration manager
12Git
Branch: Merge con Fast Forward
master
m1 m2 d1 d2
MERGE
dev
d1 d2
Non essendoci conflitti tra il branch master e dev la storia viene “appiattita” (fast forward)
nel branch di destinazione (in questo caso master)
13Git
Branch: Merge senza Fast Forward
master
m1 m2 m3 m4=m3 + d1 + d2
MERGE
dev
d1 d2
Nel commit M3 sono state committate modifche relative a dei file modificati anche nei
commit d1 e d2.
Nel caso in cui le modifiche riguardino stessi “metodi/funzioni/pezzi di codice” GIT chiedera’
all’utente di “unire/mergiare” i file manualmente e commitarli in un nuovo commit m4.
Nel caso in cui GIT non rilevi modifiche relative alla stessa porzione di codice il sistema
unira’ automaticamente i file e creera’ automaticamente un commit m4
14Git
Branch applicati: singolo branch
master
m1 m2 m3
V_1.0.0 BUG in produzione
nella versione 1.0.0
• Non posso usare la versione corrente perche’ contiene la 1.0.0 piu’ N modifiche della
futura release 1.1.0
• Recupero il tag v_1.0.0 e sistemo il problema, ma come posso “committare” sul branch
“master”? visto che contiene le modifiche per la versione successiva 1.1.0
• Se il fix necessita di ulteriori release, come lo recupero per modificarlo ulteriormente?
15Git
Branch applicati: branch multipli
devel
d1 d2
master
m1 m2 BUG in produzione m3 m4
nella versione 1.0.0
V_1.0.0 V_1.0.1 V_1.1.0
fix
f1 f2
16Git
Don’t panic!!!
La maggior parte dei comandi GIT viene mascherata da eclipse che ne permette un uso
semplificato e molto simile a sistemi di versionamento gia’ conosciuti in azienda (CVS,SVN)
17EGit
Clone
1. Utilizzare la prospettiva “GIT Repositories”
2. Selezionare clona repository
3. Inserire i riferimenti del repository
18EGit
Commit, push
19EGit
Fetch e Pull
20EGit
Creazione branch
21EGit
Merge branch
22EGit
Reset
23EGit
Stash
24EGit
Tag
25EGit
Conflitti
26EGit
Blame
27EGit
History
28Best practices
Commenti
1. *** empty log message ***
Mettere dei commenti nei commit e’ utile per
2. *** empty log message *** ritrovare le modifiche nel tempo.
3. *** empty log message ***
4. *** empty log message *** GIT obbliga l’inserimento di un commento
5. *** empty log message ***
6. *** empty log message ***
7. *** empty log message *** E’ possibile obbligare un determinato formato
8. *** empty log message *** nei commenti dei commit
9. *** empty log message ***
10. *** empty log message *** (es MTS 123: descrizione breve)
11. *** empty log message ***
29Best Practices
Branch per funzionalità
• Utile con i consulenti (un branch per mantis, un mantis per consulente)
• Possibilità di scegliere cosa andrà in produzione e cosa rimandare alla prossima release
MTS
234
c1 c2 c3
MTS
123
d1 d2
test
t1 t2
master
m1 m3
1.0.0
1.1.0
30Best Practices
Branch per versione
• Mantiene separate le linee di sviluppo
• Utile per pochi sviluppatori
Rel 1.1.0
a1 a2
master
m1 m2 m3
1.0.0
1.1.0
1.2.0
Rel 1.2.0
b1 b2
31Best Practices
Tag e Commit
Commit
• menzionare la funzionalità che si sta implementando nel commit seguendo uno standard
(es MTS 123:implementato… oppure #issue 123:implementato), così da poter sfruttare
sistemi automatici di associazione issue-commit
Tag
• «taggare» le versioni rilasciate in produzione per permettere di rintracciare facilmente i
sorgenti relativi
• utilizzare una nomeclatura omogenea nei nomi dei tag (es v_1.0.0)
• non spostare i tag per non creare confusione agli sviluppatori che si trovano una situazione
diversa dalla precedente
• commentare i tag (se il sistema di versionamento lo permette)
32Best Practices
Code review e Continuous Integration
Dev1 Code Review
(gerrit) Valuta modifica
Conferma modifica
push
Local git CR
Core Dev
repo git repo
Jenkins Jenkins
Notification result
Jenkins
Server
Repository
principale
33Migrazione
Quando, come, modalità?
Quando?
Dal 1 agosto 2016 tutti i repository presenti in cvs.intra.infocamere.it e in
ict04.ict.intra.infocamere.it saranno accessibili in sola lettura.
È quindi necessario che ogni responsabile del software chieda di migrare i propri
repository, seguendo le nuove nomenclature definite dalla PR220.
Come chiedere la migrazione?
Aprire un mantis nel progetto «Admin Source Repository CVS-GIT», specificando il
progetto da migrare e con quale modalità.
Modalità di migrazione
Mantenendo la storia Senza storia
• Viene mantenuta la storia del progetto • Non viene mantenuta la storia del progetto
• Richiede l’intervento di un amministratore • Equivale alla creazione di un nuovo
• Pianificata progetto e la chiusura del vecchio
• Tempi d’attesa determinati dalla • Viene svolta totalmente dal responsabile del
complessità della struttura del progetto software
• Tempi d’attesa ridotti
34Riferimenti
• Console Web interna
http://gd.intra.infocamere.it/
• Git Website
https://git-scm.com/
• Git Book
https://git-scm.com/book/en/v2
• Piattaforma di sviluppo software basata su git
https://github.com/
• Corso interattivo di git base (comandi da console)
https://try.github.io/
• Comandi più comuni di Git da shell
http://marklodato.github.io/visual-git-guide/index-it.html#basic-usage
http://rogerdudler.github.io/git-guide/index.it.html
35Best Practise
Norme di sicurezza
36Grazie per l’attenzione.
Puoi anche leggere
