Il documento discute i vantaggi di Git rispetto a SVN, evidenziando i problemi di latenza, stabilità e complessità collegati a SVN. Git, con la sua struttura distribuita e la gestione degli snapshot, offre un sistema più veloce e intuitivo per il versioning del codice, semplificando operazioni come branch e merge. Inoltre, il documento sottolinea l'importanza di adattarsi a Git per migliorare l'efficienza nello sviluppo software.

1. PERCHÈ GIT ?
i t
Ciò che tutti gli Sviluppatori dovrebbero sapere...

2. ...ma non osano imparare perchè è troppo sbatta!

3. C’era una volta SVN ...

4. C’era una volta SVN ...

5. Ehi fino a prova contraria
è ancora il piu’ diffuso!
C’era una volta SVN ...

6. SI, PERÒ QUALCHE DIFETTO CE L’HA!

7. SI, PERÒ QUALCHE DIFETTO CE L’HA!
Ad esempio ???

8. LATENZA

9. LATENZA
Cause possibili:

10. LATENZA
Cause possibili:
connettivita’ [rete lenta]
operazioni complesse [CPU]

11. LATENZA
Cause possibili: Risultato:
connettivita’ [rete lenta]
operazioni complesse [CPU]
Perdita di tempo
e denaro
Noia e
demotivazione

12. REPOSITORY NON RAGGIUNGIBILE

13. REPOSITORY NON RAGGIUNGIBILE
Cause possibili:

14. REPOSITORY NON RAGGIUNGIBILE
Cause possibili:
Link down
server down
VPN down
Fastweb, telecom, infostrada, ecc...
Treno, Aereo, Nave, ecc...

15. REPOSITORY NON RAGGIUNGIBILE
Cause possibili: Risultato:
Perdita di tempo
Link down e denaro
server down
Noia e
VPN down demotivazione
Fastweb, telecom, infostrada, ecc...
Treno, Aereo, Nave, ecc... Rabbia e
nervosismo

16. COMMIT TROPPO FREQUENTI
(sul trunk)

17. COMMIT TROPPO FREQUENTI
(sul trunk)
Cause possibili:

18. COMMIT TROPPO FREQUENTI
(sul trunk)
Cause possibili:
Commit ossessivo compulsivo
Apprensione

19. COMMIT TROPPO FREQUENTI
(sul trunk)
Cause possibili: Risultato:
Commit ossessivo compulsivo
Apprensione
applicazione instabile

20. TRUNK NON STABILE

21. TRUNK NON STABILE
Cause possibili:

22. TRUNK NON STABILE
Cause possibili:
Commit irresponsabili
Merge mal riusciti

23. TRUNK NON STABILE
Cause possibili: Risultato:
Rabbia e
nervosismo
Commit irresponsabili
Merge mal riusciti
Perdita di tempo
e denaro

24. MERGE!

25. MERGE!
Cause possibili:

26. MERGE!
Cause possibili:
Procedimento complesso
Conflitti

27. MERGE!
Cause possibili: Risultato:
Noia e
demotivazione
Procedimento complesso
Conflitti
Rabbia e
nervosismo
Perdita di tempo
e denaro

28. E quindi ???

29. E quindi ??? C’è GIT !!!

30. Non e’ come passare da
a

31. Non e’ come passare da
a

32. ma piuttosto da
a

33. ma piuttosto da
a

34. Git non è l’evoluzione di SVN

35. Ma una vera e propria rivoluzione

36. Git si basa su princìpi diversi

37. Git si basa su princìpi diversi
Svn funziona “Out of the box”

38. Git si basa su princìpi diversi
Svn funziona “Out of the box”
Git ha una certa
curva di apprendimento

39. Git è strutturato come un File System

40. Git è strutturato come un File System
Ehhh???

41. Git salva uno snapshot
del progetto ad ogni commit

42. Git salva uno snapshot
del progetto ad ogni commit
Svn salva le differenze (delta)
tr a l’ultimo commit e la
versione precedente

43. E allora???
Beh questo porta diversi vantaggi

44. Git crea uno snapshot
del progetto e ne calcola il checksum
(hash SHA1 [24b9da6552252987aa493b52f8696cd6d3b00373] )

45. Git crea uno snapshot
del progetto e ne calcola il checksum
(hash SHA1 [24b9da6552252987aa493b52f8696cd6d3b00373] )
In questo modo si accorge di
qualsiasi modifica ed impedisce
di fare operazioni pericolose

46. Git crea uno snapshot
del progetto e ne calcola il checksum
(hash SHA1 [24b9da6552252987aa493b52f8696cd6d3b00373] )
In questo modo si accorge di
qualsiasi modifica ed impedisce
di fare operazioni pericolose
Si può fare di tutto, ma
semplicemente è più faticoso fare
stupidate che fare le cose per bene.
(vedi Ruby on Rails )

47. Git è Distribuito

48. Git è Distribuito
Gratuitamente in
metropolitana???

49. No!
Significa che ogni sviluppatore ha in
locale la copia dell’intero Repository

50. No!
Significa che ogni sviluppatore ha in
locale la copia dell’intero Repository
Quindi il Repositor y è
ridonandato e si riducono i
Point of failure

51. No!
Significa che ogni sviluppatore ha in
locale la copia dell’intero Repository
Quindi il Repositor y è
ridonandato e si riducono i
Point of failure
Inoltre tutte le operazioni sono
praticamente istantanee.

52. Quindi Git è Veloce!
Veloce!
VELOCE!

53. Inoltre il processo di merge è
molto più semplice
(No Rev. bensì snapshot)
L’imperativo quindi è
sfruttare al massimo
i branch
Tanto il repository è locale, non
si rischia di fare pasticci.

54. ?
Non ho capito se è distribuito
in metropolitana o no.

55. Questo e’ SVN
Repository principale
Developer

56. Questo e’ Git
Repository principale
1/20 di SVN
Developer

57. La feature del repository distribuito permette di
decidere quale sarà il repository principale.

58. La feature del repository distribuito permette di
decidere quale sarà il repository principale.
Chi gestisce il repository principale ha il potere
di decidere cosa “mergiare”

59. La feature del repository distribuito permette di
decidere quale sarà il repository principale.
Chi gestisce il repository principale ha il potere
di decidere cosa “mergiare”
ma soprattutto non dovrà fare un merge tra
innumerevoli commit, bensì solamente l’ultima
versione del master (trunk) aggiornata (da colui che
ha fatto le modifiche).

60. RELAX
Relax
RELAX!
STOP! ai merge che durano 1/2 giornata

61. No Revision!

62. No Revision!
Git riconosce automaticamente
gli eventi di branch

63. No Revision!
Git riconosce automaticamente
gli eventi di branch
e registra automaticamente gli eventi di merge
(quali branch, committer, ecc...)

64. 5 diversi algoritmi di merge!
maggiori probabilità di successo
meno conflitti

65. 5 diversi algoritmi di merge!
maggiori probabilità di successo
meno conflitti
Finalmente branch e merge
diventano operazioni semplici.

66. Perchè con SVN nessuno vuole usare i branch?
Perchè non sempre è necessario!
Oppure perchè è troppo complesso e oneroso,
e non ne va mai bene uno!
E meno lo si fa, meno lo si impara.

67. Con Git è un’operazione semplice, all’ordine del giorno.
Per questo branch e merge diventano operazioni naturali

68. Un paio di comandi evoluti che fanno la differenza...

69. Rebase
REBASE
Per integrare in maniera rapida e indolore,
nel ramo corrente,
le patch provenienti da un altro ramo.
REBASE

70. Stash
STASH
Per “parcheggiare” temporaneamente le modifiche locali,
applicare la/e patch, committare, e
STASH
tornare ai propri sviluppi come se niente fosse accaduto

71. stash
clone STATUS
reset
BRANCH
add
COMMIT
merge CHECKOUT
rebase diff

72. ...rimane solamente da provare...

73. Created by
Questo non sono io,
è Arthur Christmas© !
Però c’è una certa somiglianza.
http://about.me/mauroferratello