Newsgroup: it.comp.www.php
Titolo: Da SVN a Git ? Ne vale la pena?

Buondi,
 
Dove lavoro stiamo ampliando il team con nuovi programmatori e collaboratori.
 
Attualmente utiliziamo SVN, e benche' siamo un team minuscolo, 2 resident e di tanto in tanto qualche esterno, e' capitato piu' di una volta di avere millanta problemi di merging, fare update su deployment sbagliati con versioni sbagliate (come postai e mi consigliaste di utilizzare svn tag :-) ), problemi con i file binari (non so esattamente se dovuto a svn o qualche altro problema) e praticamente incubi nel creare e riaccorpare branch.
 
La situazione sara' di avere piu' persone in ufficio ed anche piu' persone esterne, per questo stiamo pensando di passare a git perche' sembra piu' adatto in questo tipo di situazioni, ma siccome cambiare CVS e' un passo importante vi chiedo se avete esperienza con git (io lo uso giusto per manutenere alcuni repos su github) se il cambio vale la candela, quello che ci serve:
 
- definire tag o versioni o qualsiasi cosa in modo che si possa continuare lo sviluppo ma continuare a creare deployment riferiti alla versione "stabile"
- controllo di quello che va "live"
- gestire branch
- essere alla moda per fare il bello al Bar.. ahah .. no questo, no
 
 
Ma soprattutto mi interesserebbe capire se ci sono impatti negativi a passare da svn a git
 
Grazie
 
J.

 Ma soprattutto mi interesserebbe capire se ci sono impatti negativi a passare da svn a git
 
Nessuno. Praticamente tutto il mondo open source č passato a git, un
motivo ci sarą :)
 
Io sto collaborando ad un progetto open
(
https://github.com/silverstripe/sapphire
) hostato su github, č
spettacolare. Considera che siamo almeno un centinaio di persone a
collaborare, anche se non so esattamente a quanto ammonti questo dato.
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 

 passare da svn a git
 
Partiamo da questi.
 
Se prendi la codebase e brutalmente la "gitti" perdi tutta la history del 
svn. Ci sono dei tool che consentono di trasformare un repository svn in 
uni git, ma non li ho mai provati. Ho sempre iniziato progetti nuovi in 
git.
 
Il secondo è che ogni progetto è un repository a sé. In svn (e cvs) puoi 
avere un singolo repository e scaricarti e lavorare sul singolo project 
senza influenzare gli altri. In git, quando forki, forki tutto il repo, 
quindi ti trovi in locale tutti i progetti, se ne metti più di uno nello 
stesso repo.
 
Il terzo, collegato al secondo, è che gestirsi un "server git" con queste 
premesse è un bagno di sangue, quindi è economicamente e sanitàmentalmente 
preferibile pagare github o bitbucket (che offre repo privati gratuiti 
fino a 5 sviluppatori, se interessa ;) piuttosto che installarselo e 
gestirselo.
Corollario: se ti serve un account su bitbucket, chiedimelo, così ti 
mando l'invito e guadagno, forse guadagnamo entrambi, un utente in più 
sui miei repository :D)
 
Andando avanti coi difetti, gestire degli hook (pre e post-commit, push, 
branch, ecc.) è molto più complesso, data la natura decentralizzata del 
tutto. Rischi di fare degli hook che funzionano solo sulla tua macchina 
ma non sul repo centrale o sui repo degli altri utenti.
 
Infine ultimo: essendo decentralizzato è necessari capirlo bene per 
sfruttarlo bene. E il fatto che ci siano fior di articoli online sul 
"best git workflow" ti fa capire che non c'è ancora un vero best git 
workflow, perché è talmente flessibile che va adattato a ogni situazione.
 
Un esempio banale: hai il progetto su github, lo cloni in locale, fai un 
branch (per non lavorare sul "trunk" che qui si chiama master) e inizi le 
tue modifiche. Man mano che funzionano le committi, e a fine giornata le 
pushi su github. Vai a casa, ti viene in mente un bug del cacchio (-1 al 
posto di +1 in una riga) che hai introdotto e pensi "clono qui, correggo, 
pusho e così non me ne dimentico domani mattina".
 
Cloni e... non c'è il tuo branch!!
 
Questo perché è decentralizzato. Ogni clone del repo è un server, quindi 
i branch di uno non necessariamente sono sugli altri nodi.
 
Soluzione: il giorno dopo, in ufficio, pushi il tuo branch su un branch 
remoto su github e poi sei a posto.
 
Ecco cosa intendevo quando dicevo che il supporto ai branch è anche 
troppo spinto.
Tu in locale puoi fare branch senza preoccuparti che vadano a interferire 
coi branch degli altri, anche se hanno lo stesso nome, perché tu in 
realtà hai un repo locale totalmente scollegato dagli altri. Se vuoi 
branchare su un altro repo remoto, devi creare il branch sul remoto, e a 
quel punto ti avvisa se ce n'è già uno con lo stesso nome.
 
Va quindi decisa una politica di naming dei branch sul repo "centrale", 
ma devi farla comunque anche con svn. L'importante è riuscire ad 
abituarsi a pensare in "repo locale" e "repo remoto".
 
Se pensi che tutta questa potenza ti salvi dai conflitti, scordatelo.
 
Se lavorate in due allo stesso file, modificando le stesse righe, o se lo 
modificate tanto che l'algoritmo di merging non riesce a ricostruire la 
diff, avrai esattamente la stessa situazione di svn al merge.
 
Il vantaggio di git è che, essendo branch locali, spinge a fare micro-
commit continui.
Mentre in svn sei abituato a committare solo quando hai finito di 
implementare una certa funzionalità (non importa quanto grossa) o a fine 
giornata giusto per andare sul sicuro, con git dovresti committare il più 
spesso possibile. Anche ogni 5-10 minuti. Ogni funzione che crei, ogni 
file che modifichi, committa.
 
Questo ti porta a sfruttare la potenza di "git bisect".
 
Esempio: lavorate in 3 su un progetto, per una settimana di fila. Lo 
finite e vi accorgete che, quando lo lanciate, il DB si spacca (spero 
foste sul server di test :P). Guardando il codice non capite cosa stia 
succedendo, e allora fate un "git bisect" indicando la versione in cui 
sicuramente funzionava, e l'ultima committata/pushata. Lui recupera 
quella in mezzo. La lanciate. Se il programma si spacca gli dite "era 
corretta prima", se funziona "era corretta anche dopo", quindi continuate 
di bisect finché non trovate le due versioni consecutive tra cui il 
software spacca e non spacca. Analizzando il diff tra le due vedete dov'è 
il bug. E con "git blame" sapete anche chi ha introdotto la modifica che 
spacca tutto. :)
 
Consiglio, tempo permettendo, di prendere un sideproject e provare a 
partire da zero con git per prenderci mano. Ci vorrà più tempo, ma almeno 
non rischiate su codice di produzione.
 
Bye.

 "git bisect"
 
Questo non lo conoscevo, che potenza git!!


 Bye
 
Grazie
 
Ciao!

 Per i repo privati e' meglio github o bitbucket, o e' a simpatia?
 
Github ha acquisito molto "momentum" (cioè quantità di moto) ultimamente 
proprio per la rapidità di fare fork, l'intefaccia abbastanza gradevole 
e il fatto che parte della struttura è essa stessa opensource.
Bitbucket ha alle spalle atlassian e da quello che leggo gli utenti 
"avanzati" lo reputano più maturo e feature-rich, io non sono abbastanza 
avanzato da notare le differenze, uso bitbucket per i repo privati e 
github perché alcuni progetti che mi interessano usano quello.

 Per i repo privati e' meglio github o bitbucket, o e' a simpatia?
 
A simpatia. Dovresti vedere le varie configurazioni e decidere, in base 
alle dimensioni della codebase e al numero di sviluppatori, quale 
conviene economicamente.
 
Bye.
 
P.S.: Da domani sono al JSday/PHPday fino a sabato sera, quindi 
difficilmente risponderò sul ng, ma le mail dovrei riuscire a leggerle.

 Per i repo privati e' meglio github o bitbucket, o e' a simpatia?
 



Un vantaggio basilare � il supporto per lo sviluppo non lineare del 
software es. terra terra:
http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
 
 
Il sistema � molto diverso da cvs e git, il problema � che se gli 
sviluppatori sono MOLTO legati a cvs e svn non riusciranno mai a 
sfruttarne le pontenzialit� e continueranno ad usare git come svn e cvs. :)
http://stackoverflow.com/questions/871/why-is-git-better-than-subversion
 
http://programminghacks.net/2011/08/30/perche-passare-da-svn-a-git/
 
 
-- 
http://www.evilripper.net
 
http://www.flickr.com/photos/evilripper/