Controllo di versione e Git

978 views

Published on

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.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
978
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
21
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Controllo di versione e Git

  1. 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. 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. 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. 4. Metodologie di sviluppo... ● Sviluppatore singolo ● Più sviluppatori – Sviluppo con copie multiple – Sviluppo con copia unica
  5. 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. 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. 7. Sviluppatori multipli (Sviluppo con copia individuale) Sviluppatore-1 Sviluppatore-2 Sviluppatore-3 PC-1 PC-2 PC-3 server
  8. 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. 9. Sviluppatori multipli (Sviluppo con copia unica) Sviluppatore-1 Sviluppatore-2 Sviluppatore-3 server
  10. 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. 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. 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. 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. 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. 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. 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. 17. 40 anni di versioning SCCS & RCS ('70) CVS (2006) Subversion (2001) GIT (2005)
  18. 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. 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. 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. 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. 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. 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. 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
  25. 25. 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)
  26. 26. Ciao, sono Bob Ciao, sono Bob
  27. 27. Pentitevi, infedeli!! Pentitevi, infedeli!!
  28. 28. $ mkdir librosacro $ cd librosacro $ git init
  29. 29. Capitolo 1 NerdGenesi All'inizio ci fu Bob, che era l'origine di tutto.  'capitolo 1.txt' salvato
  30. 30. $ git status # On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to  include in what will be committed) # # chapter1.txt
  31. 31. $ 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
  32. 32. $ 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  
  33. 33. 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
  34. 34. 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'
  35. 35. Ciao, sono Tim Ciao, sono TimInsieme scriveremo...Insieme scriveremo... Il Librone sacro!
  36. 36. $ git remote add origin git://librone/sacro.git $ git push origin master Protocolli utilizzabili: Git, ssh. http, local.
  37. 37. $ git clone git://librone/sacro.git $ cd librosacro
  38. 38. Capitolo 2 NerdCloning E poi ci fu Tim, che  pensava che era cosa buona E giusta.  'capitolo 2.txt' salvato
  39. 39. $ 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 
  40. 40. $ 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'
  41. 41. 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à
  42. 42. 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
  43. 43. $ git ­b comandamenti $ git branch master * comandamenti
  44. 44. $ 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 
  45. 45. $ git checkout comandamenti $ git commit ­m “Primo  comandamento” $ git commit ­m “Secondo  comandamento” $ git checkout master $ git merge commandments
  46. 46. master mastermaster comandamenti master
  47. 47. master mastermaster comandamenti masterprecetti
  48. 48. Le branch sono utili ...ma possono diventare complicate da gestire!
  49. 49. $ 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.
  50. 50. $ <<<<<<< HEAD:Capitolo 1.txt All'inizio ci fu Bob, che ======= All'inizio ci fu Tim, che >>>>>>> comandamenti:Capitolo 1.txt Commit? Discard?Commit!
  51. 51. Fork!
  52. 52. $ git remote add libroditim git://libroditim/librone.git $ git push libroditim master
  53. 53. * Installazione * GitHub * Demo project Next: Workshop
  54. 54. 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
  55. 55. 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

×