Git: sistema di versionamento distribuito

Transcript

1 IC-GEN-Presentazione Git: sistema di versionamento distribuito Igor Maculan Andrea Vanzan Padova, 18/02/2016

2 Sommario Versionare Git, i concetti di base EGIT: Eclipse + Git Best practices 1

3 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

4 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

5 Versionare VCS Centralizzato (CVCS) Unico server centrale Nessun versionamento locale Connessione al server obbligatoria Esempi CVS SVN 4

6 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

7 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

8 Git Chi lo usa? 7

9 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

10 Git Tre stati WorkStation La directory di Git è dove Git salva i metadati e 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' 9

11 Git 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 Checkout/Reset Commit Fetch Push Remote Server Push.git Dir Fetch.git Dir 10

12 Git Utilizzo classico: Sviluppatore Server Centrale 11

13 Git 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 principale fork Dev1 Repo push/pull Dev1 Dev2 Repo push/pull Dev2 Integration manager pull request 12

14 Git 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) 13

15 Git 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 14

16 Git Branch applicati: singolo branch master m1 m2 m3 V_1.0.0 BUG in produzione nella versione Non posso usare la versione corrente perche contiene la piu N modifiche della futura release 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 Se il fix necessita di ulteriori release, come lo recupero per modificarlo ulteriormente? 15

17 Git Branch applicati: branch multipli devel d1 d2 master m1 m2 BUG in produzione nella versione m3 m4 V_1.0.0 V_1.0.1 V_1.1.0 fix f1 f2 16

18 Git 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) 17

19 EGit Clone 1. Utilizzare la prospettiva GIT Repositories 2. Selezionare clona repository 3. Inserire i riferimenti del repository 18

20 EGit Commit, push 19

21 EGit Fetch e Pull 20

22 EGit Creazione branch 21

23 EGit Merge branch 22

24 EGit Reset 23

25 EGit Stash 24

26 EGit Tag 25

27 EGit Conflitti 26

28 EGit Blame 27

29 EGit History 28

30 Best practices Commenti 1. *** empty log message *** 2. *** empty log message *** 3. *** empty log message *** 4. *** empty log message *** 5. *** empty log message *** 6. *** empty log message *** 7. *** empty log message *** 8. *** empty log message *** 9. *** empty log message *** 10. *** empty log message *** 11. *** empty log message *** Mettere dei commenti nei commit e utile per ritrovare le modifiche nel tempo. GIT obbliga l inserimento di un commento E possibile obbligare un determinato formato nei commenti dei commit (es MTS 123: descrizione breve) 29

31 Best 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 test master m MTS 123 d1 d2 t1 t2 m

32 Best Practices Branch per versione Mantiene separate le linee di sviluppo Utile per pochi sviluppatori Rel a1 a2 master m1 m2 m Rel b1 b2 31

33 Best 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) 32

34 Best Practices Code review e Continuous Integration Dev1 Code Review (gerrit) Valuta modifica Conferma modifica Local git repo push CR git repo Core Dev Jenkins Notification Jenkins result Jenkins Server Repository principale 33

35 Migrazione 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 Viene mantenuta la storia del progetto Richiede l intervento di un amministratore Pianificata Tempi d attesa determinati dalla complessità della struttura del progetto Senza storia Non viene mantenuta la storia del progetto Equivale alla creazione di un nuovo progetto e la chiusura del vecchio Viene svolta totalmente dal responsabile del software Tempi d attesa ridotti 34

36 Riferimenti Console Web interna Git Website Git Book Piattaforma di sviluppo software basata su git Corso interattivo di git base (comandi da console) Comandi più comuni di Git da shell

37 Best Practise Norme di sicurezza 36

38 Grazie per l attenzione.