GIT Tutorial? meglio capire qualche concetto, prima..

dove mi ero impuntato, e come ho fatto a superare le concezioni errate mutuate da SVN.

Molte magagne possono capitare quando non è chiaro quel che si sta facendo, e questo è tanto più vero quanto più lo strumento da maneggiare è "particolare", come GIT appunto.

(nb: Parlando di DVCS, Joel Spolsky c'era cascato prima di me..)

Ecco le cose che mi stanno aiutando a capire, man mano che ne faccio tesoro:

1. GIT non è SVN

e fino qui ci si arrivava.. ma cosa significa?

significa che GIT non ha in mente un modello client/server, non ragiona in termini di "come è messa la mia copia di lavoro rispetto al server?", e così via.

Prima ci si sofferma a capire questo concetto, e meglio è!

Come ci si può accorgere che stiamo usando GIT come fosse un client/server classico?

Ad esempio se vi manca il comando "svn info", a cui siete tanto devoti.. :)

GIT sta a SVN come Torrent sta all'FTP

In altri termini, ogni singola working copy, è di fatto anche un server! non ha bisogno di nessun altro nodo per funzionare, non c'è bisogno di nessun "svn info", dato che la vostra cartella di lavoro è anche il vostro server!

NB: occhio anche al fatto che se siete in una cartella ospite di un repository GIT, anche se non siete sotto-traccia, il comando GIT fa comunque riferimento al padre, da shell..

2. I repository GIT si palleggiano i propri branch

Con facilità un repository GIT (es. il vostro repository di lavoro) può agganciarsi ad altri repository "gemelli", scambiandosi i propri branch in modo da mantenere allineate le parti necessarie.

Avete capito bene, le parti necessarie: se devi fare delle prove, e crei un branch locale, non c'e' nessun bisogno di spingere quel branch sul repository "gemello", fino a che qualcuno non ne abbia bisogno.

Che significa? ripensate a SVN: se avete bisogno di fare un branch, dovete farlo sul server! e tutti i branch restano nella storia del server, senza possibilità di "dimenticarli".

Con GIT, ammesso che uno dei repository sia "più repository" degli altri, diciamo il nodo "principale", questo non è necessario: sul repository "principale" finiranno solo i branch, e gli aggiornamenti che riterremo utili.

AH! e i branch possiamo usarli con molta meno paura di incappare in conflitti durante i merge rispetto a quel che si ha con SVN.

Grazie all'architettura di GIT, infatti, ogni commit è atomico rispetto al repository: di fatto il repository immagazzina il diff relativo a un certo commit, per tutte le variazioni di quel commit, in modo atomico, memorizzando tutti insieme i file aggiunti/modificati/eliminati.

Se questo passaggio non vi è completamente chiaro, cercate di approfondirlo, potrete spiegarvi certe situazioni che vi passano sotto gli occhi usando GIT.

3. La "working copy" *non* esiste, è un repository GIT

Da cui si deduce che:

a. ogni nostra cartella può diventare un repository GIT, semplicemente lanciando il comando:

>>> git init

b. agganciare il nostro repository locale a un repository "principale" è facile con il comando "git remote", usato per collezionare sul repository locale le informazioni relative ai nostri repository gemelli. Ad esempio per "agganciare" il nostro repository centrale potremmo usare il comando:

>>> git remote add origin git@git.progetti.org:progetto-test/progetto.git 

c. potremmo agganciare più repository "gemelli" con cui palleggiarci i branch

Per ora basta così..

Spero che abbia un po' illuminato la strada di chi come me ancora la pensava alla SVN.. e se usate mac, usate GitX !!!

Ultima raccomandazione: non fatevi scoraggiare dalle eventuali difficoltà iniziali, vale certamente la pena di passare a GIT o equivalente DVCS per tutti i vantaggi che ne potrete ottenere.

immagine: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

Share this on

Share |

On same topics

Commenti

comments powered by Disqus