In twitter c’è un’accesa discussione sull’argomento Git. Ora per chi non mi conosce io sono quello che ha sempre detto “Git mi fa Cag****” perchè è troppo complesso e che ha sempre detto, “però debbo dire che non lo conosco bene”.
Ora che lo conosco abbastanza bene, posso senza dubbio dire che è veramente interessante, ma che di contro è complesso da usare e ha una barriera di ingresso sicuramente più alta.
Come per qualsiasi altra tecnologia/Pattern/etc l’importante è, conoscerne il più possibile, capire cosa ci si può fare, per costruirsi una “cassetta degli attrezzi più ampia possibile” cosi da poter scegliere l’attrezzo più adatto in base al problema.
Chi dice che con l’avvento di Git tutti gli altri source control sono morti, secondo me sbaglia alla grande, perchè sono due tool differenti. Il problema è questo: in molte situazioni vedi team di persone che riescono a confondersi anche con un centralizzato, che faticano a capire il concetto di branch, e che hanno paura del merge, oppure che fanno check-in ogni 20 giorni perché stanno lavorando ad una parte importante e non vogliono destabilizzare il team. Se un team non riesce ad usare correttamente un centralizzato, il rischio che si crei del chaos con un distribuito ci sta.
Conosco molte persone, tra cui io, che tentando di usare git in maniera minimale ha trovato problemi, che non sono mai comparsi con un altro source control, anche distribuito come Mercurial. Ho sentito persone che anche in 2 hanno trovato difficoltà usando Git per alcune settimane, fino a che non hanno trovato il modo giusto di lavorare. Conosco anche persone che usano Git, ma che fanno push e pull di continuo, perchè: “altrimenti perdiamo sempre tempo a fare merge”. Vorrei anche capire chi usa git sfruttandolo veramente al massimo e quindi fa branch più volte al giorno e poi decide se fare merge o rebase in base a come vuole strutturare la linearità delle sue “linee di codice” etc etc, e chi invece lo usa perchè “è cool” e lo usa poco più di un centralizzato. Es. commit, commit, poi però subito push perchè senno qualcun altro mi fa push e poi debbo fare merge e non ho voglia!!. 
Vorrei capire quanti di quelli che osannano Git lo abbiano mai usato in un team composto di “sviluppatori medi”, di più di 10 persone e non nella situazione di team di 3 persone di sviluppatori skillati. La necessità di ricorrere spesso alla riga di comando, per uno che ci ha lavorato per anni è un vantaggio, per uno che usa solamente UI può essere un casino. Dopo 3 ore passare a riga di comando ti dici “beh, faccio prima a fare un git add-commit che usare un tool grafico”, vero, ma perchè hai un modello di lavoro corretto.
Poi vedi sviluppatori che hanno solution di 50 progetti, che hanno 120 file modificati, aprire la GUI del loro source control ed iniziare a dire: “allora, questo lo mando su, questo no perchè non è pronto, questo si, questo no”, a loro la riga di comando non è possibile proporla. (che poi sia necessario cambiare il flusso di lavoro siamo daccordo, ma non è sempre facile")
Quando allora mi serve un DVCS? Ecco la situazione che mi si è posta ieri.
Esempio su github di un host di controlli WPF su host remoto , la clono in locale e vedo che ci sono piccoli bug (è solo un esempio per cui ci sta).
1) Fixo un piccolo bug, faccio commit in locale
2) fixo un altro bug, faccio ancora commit in locale
3) un’altra persona del team deve vedere quello che ho fatto
--Fork del progetto
--git remote add myfork …
--git fetch myfork
--git branch –set-upstream ….
--git push
4) ora ho il mio fork privato ci posso lavorare (qui ho il vantaggio di un DVCS)
5) debbo fare una nuova feature a inizio a lavorarci e faccio 3 commit locali
6) mi accorgo che la strada forse non è quella giusta faccio branch prendendo il commit da cui ero stabile creando Tentative1
7) faccio un’altra branch, inizio a prendere una strada differente: branch tentative2
8) realizzo che la prima strada era la migliore, faccio gli ultimi fix, rebaso la branch
9) faccio push, grazie al rebase gli altri sviluppatori vedono il mio flusso lineare e non le branch
10) cancello tutte le branch non più utilizzate
Ora questo me lo sognavo con un centralizzato, ma è tutto a riga di comando ed ora che conosco git è tutto abbastanza semplice, ma per saperlo fare di concetti ne ho dovuti imparare un po’.
Per questa ragione amo sempre di più il tool git-tf che mi permette di usare un normale centralizzato di TFS come server, ma localmente uso git, cosi chi vuole usa git, chi non vuole usa il centralizzato, ovvero il meglio dei due mondi. In realtà normalmente lavoro con il centralizzato, quando so di dovere sperimentare, passo alla cartella di git, faccio un git-tf pull ed inizio a sperimentare per poi fare check-in, perchè la flessiblità di fare branch, merge, rebase, non ha prezzo quando capisci come funziona. Ti trovi alla sera che puoi avere fatto anche 10 branch.
Ovvero uso la tecnologia che in una data situazione mi rende piu produttivo, e sono contento che TFS con git-tf supporti questa situazione mista, cosi ogniuno può usare il flusso di lavoro che preferisce.
Alk.