Git o SVN, cosa scegliere?
Qual è il miglior strumento di controllo di versione?
Entrambi hanno vantaggi e svantaggi, esiste solo lo strumento che meglio si adatta alle nostre necessità.
Qui ho cercato di spiegare i motivi per cui Git si adatta meglio a quelli che sono i nostri requisiti dopo alcuni anni di utilizzo (a volte frustrante) di SVN.
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
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 )
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.
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.
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
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