Introduzione a Git
•
11 recomendaciones•2,522 vistas
Presentazione su Git tenuta all'incontro del PHP Users Group Friuli il 27/06/2012
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Introduzione a Git
Similar a Introduzione a Git (20)
Más de Stefano Valle
Introduzione a Git
- 1. Introduzione a GIT Il sistema di Source Control distribuito PHP User Group Friuli, 27/06/2012
- 6. COME SIAMO ARRIVATI A GIT?
- 7. 7
- 8. CVS >> SVN 8
- 10. SVN >> GIT 10
- 12. E’ MOLTO VELOCE
- 13. E’ Distribuito Pro Git - http://git-scm.com/book
- 14. PERMETTE DI LAVORARE OFFLINE
- 15. Incoraggia sviluppo non lineare Pro Git - http://git-scm.com/book
- 16. Come funzionano gli altri? Pro Git - http://git-scm.com/book 16
- 17. Come funziona GIT? Pro Git - http://git-scm.com/book 17
- 18. LE BASI
- 19. Installare Git • Debian/Ubuntu apt-get install git-core • RedHat/Fedora/CentOS yum install git • Disponibile per altre distribuzioni e SO: http://git-scm.com/downloads 19
- 20. Configurare Git • Identità: git config --global user.name "John Doe" git config --global user.email johndoe@example.com • Editor: git config --global core.editor emacs • Verifica parametri: git config --list 20
- 21. «helper» per la console 21
- 23. PARTIAMO!
- 24. init • Inizializza un nuovo repository all’interno della cartella corrente • Crea la sottocartella .git che conterrà tutti i file ad uso interno di git 24
- 25. clone • Clona un repository git esistente 25
- 26. add • Aggiunge un nuovo file a git, che da quel momento ne terrà traccia • Aggiunge un file modificato all’area di staging (che vediamo fra poco) 26
- 27. commit • Memorizza lo snapshot delle modifiche fatte • Obbligatorio inserire un messaggio • Identificato da hash SHA-1 27
- 28. Struttura di un commit 28
- 29. Ciclo di vita di un file Non Non gestito Modificato In stage modificato aggiunta del file modifica del file staging del file rimozione del file commit 29
- 30. status • Mostra lo stato in cui si trovano i file del repository 30
- 31. log • Mostra la storia dei commit • Per ciascuno elenca autore e messaggio 31
- 32. DEMO 1
- 33. branch • La killer feature di GIT! • Consente di continuare lo sviluppo su una nuova feature senza impattare sul lavoro corrente 33
- 34. Un po’ di internals Pro Git - http://git-scm.com/book 34
- 35. git branch testing Pro Git - http://git-scm.com/book 35
- 36. Su quale branch stiamo lavorando? Pro Git - http://git-scm.com/book 36
- 37. checkout • Consente di passare da un branch all’altro • (o anche da un commit all’altro) 37
- 38. git checkout testing Pro Git - http://git-scm.com/book 38
- 39. DEMO 2 - BRANCHING
- 40. merge • Incorpora sul branch principale le modifiche fatte su un altro branch • Assieme a branch, è un altro comando che git incentiva ad usare spesso 40
- 41. merge fast-forward Pro Git - http://git-scm.com/book 41
- 42. merge Non fast-forward Pro Git - http://git-scm.com/book 42
- 43. DEMO 2 – OPERAZIONI DI MERGE
- 45. rebase • Altro modo per integrare le modifiche di un branch • Prende linearmente tutte le modifiche fatte su un branch e le applica ad un altro 45
- 46. rebase Pro Git - http://git-scm.com/book 46
- 47. Merge Rebase Prende gli ultimi commit e li Applica le modifiche di un «mette assieme», creando branch linearmente su un un nuovo commit di merge nuovo branch Pro Git - http://git-scm.com/book 47
- 48. Git distribuito repository condiviso sviluppatore 1 sviluppatore 2 sviluppatore 3 48
- 49. remote • Consente di gestire repository remoti • Sincronizzandoli con il proprio repo locale 49
- 50. fetch • Scarica branch e dati da un repository remoto 50
- 51. pull • Scarica dati da un repository remoto e tenta di fare il merge con il branch corrente • pull = fetch + merge 51
- 52. push • Invia branch e dati ad un repository remoto • Consente di aggiornare il repository remoto con le modifiche fatte localmente 52
- 53. DEMO 3 - REBASE
- 55. Github 55
- 56. Bitbucket 56
- 57. DEMO 4 – GIT WORKFLOW
- 58. Premessa • Usate git per qualsiasi progetto • Anche se sviluppate da soli • Anche se lavorate solo in locale 58
- 59. Branches 59
- 60. Long-running branches • master – Allineato con versione on-line • develop – Allineato con versione in sviluppo 60
- 61. Topic branches • Branch in cui sviluppare feature • Feature terminata (e testata)? merge su develop • Al termine, il branch viene cancellato 61
- 62. Hotfix branches • Per bug fix / interventi veloci • Fix terminato, merge su develop • Cancellato al termine del merge • Ha una vita molto breve 62
- 63. COMANDI UTILI
- 64. diff • Mostra le differenze introdotte dalle modifiche non committate 64
- 65. tag • Consente di contrassegnare un commit • Spesso usato per identificare le versioni del progetto 65
- 66. stash • Salva temporaneamente il contenuto della working directory, ripulendola • Consente di cambiare branch in qualsiasi momento 66
- 67. reset • Il comando più ambiguo! • Consente di: – Togliere file dallo staging – Eliminare definitivamente file dallo staging – Riavvolgere storia commit 67
- 68. revert • Consente di annullare uno o più commit • Crea un nuovo commit che annulla l’effetto dei commit da eliminare 68
- 69. submodule • Consente di includere un repository git all’interno del proprio progetto git • Utile per caricare librerie esterne 69
- 70. BEST PRACTICES
- 71. Commit • Fare commit spesso • Un commit deve inglobare un insieme atomico di modifiche • NON lavorare N giorni in attesa di aver finito il task! • Al massimo fare tutti i commit alla fine, sfruttando lo staging 71
- 72. Testo del commit • Sommario da max 50 caratteri • Seguito (eventualmente) da descrizione più dettagliata • Forma imperativa (es. «Add products section», ...) 72
- 73. COMMIT E PUSH PRIMA DEL COLLEGA!
- 74. LAVORARE TUTTI SUL MASTER, HUH?
- 75. TESTARE IL CODICE PRIMA DI COMMITTARLO
- 77. LAVORARE CON GIT E’ PIACEVOLE
- 78. Per approfondire: • Pro git: http://git-scm.com/book • http://gitref.org/ • http://gitready.com/ 78
- 79. DUBBI? DOMANDE?
- 81. Grazie per l’attenzione Stefano Valle s.valle@mvassociati.it @stefanovalle
- 82. Referenze Immagini • http://www.flickr.com/photos/boston_public_library/6323438849 / • http://www.flickr.com/photos/a03575/3632344397 / • http://www.flickr.com/photos/chiperoni/3456589962/ • http://www.flickr.com/photos/53370644@ N06/4976492450 • http://www.flickr.com/photos/lululemonathletica/4911299076/ • http://www.flickr.com/photos/psi_mon/3473153641/ • http://www.flickr.com/photos/masstravel/7454482646/ • http://www.flickr.com/photos/53370644@ N06/4976497160/ • http://www.flickr.com/photos/53370644@ N06/4975888229/ • http://www.flickr.com/photos/53370644@ N06/4976490816/ • http://www.flickr.com/photos/visualgrammar/2997271008/ • http://www.flickr.com/photos/ejcdelahoya/2504629292 / • http://www.flickr.com/photos/altuwa/3582839737 • http://www.flickr.com/photos/marine_corps/5132830788/ • http://www.flickr.com/photos/72213316@ N00/5028110521/ • http://www.flickr.com/photos/stevengrayphotography/6893446706/
Notas del editor
- Intro + sondaggio
- 1 o 2 ordini di grandezza più veloce di SVN
- L’intero repo si trova in tutti nella macchina di ogni sviluppatore
- Quasi tutte le operazioni sono localiLa clonazione del repo (operazione più lenta) scarica tutti i dati e tutta la storia
- Si adatta alla realtà fatta di interruzioni, fix da fare velocemente, lavoro in parallelo da parte di più sviluppatori
- Mantengono i delta
- Commit sono snapshots, i file modificati vengono copiati, i file non modificati mantengono la stessa referenza
- Anche per windows
- Si parte da qui per continuare a lavorare su un repo già fatto o per contribuire ad un progetto
- Doppia funzione
- git log --pretty=oneline
- Capiamo come funziona per comprendere perchè è così veloce e quindi perchè ha senso usare branch senza paura
- Definire fast-forward
- Quasi tutte le operazioni sono localiLa clonazione del repo (operazione più lenta) scarica tutti i dati e tutta la storia
- Esempi non ffVantaggi rebase: mantiene la storia dei commit lineareNon facciamo ora esemi, eventualmente alla fine a richiesta
- git remote –vcgit remote add githubgit@github.com:schacon/hw.git
- Quasi tutte le operazioni sono localiLa clonazione del repo (operazione più lenta) scarica tutti i dati e tutta la storia
- L’undo dello sviluppatore
- A cui aggiungere eventualmente branch di hotfixPer semplificare si può togliere branch develop
- Git fa cancellare solo branch completamente mergeati
- Non in stage: git diffIn stage: git diff --cachedEntrambe: git diff HEADSpecifico commit: git diff [commit]
- git tag –a [tagname] >> per annotated tagsgit push –taggit checkout [tagname]
- git stashgit stash listgit stash apply
- Rimuovere da staging: git reset HEAD o git reset HEAD – [nomefile]Differenze -- soft, -- hard
- Perlomeno su branch pubblici
- Come coding conventionsgitflow