In questo breve articolo vedremo in maniera pratica ed immediata quali passi (o più propriamente comandi) occorre seguire per lavorare in team su un progetto software che utilizza Git come DCVS.

Scenario

Lo scenario è il seguente: abbiamo un progetto software chiamato TeamWork che è stato creato inizialmente dallo sviluppatore BestJavaProgrammer il quale si è anche occupato di inizializzare un repository git per tale progetto.
Tutti i programmatori che partecipano a questo articolo hanno dei SO con shell complete tramite le quali posso lanciare comandi git, avendo preventivamente installato git stesso!

Questo repository si raggiunge tramite la seguente url:

[GITURL] = prot://path.to.git/.../teamwork

dove prot può essere uno dei protocolli supportati da Git, come git, https, etc…

Inizio dei lavori

Ora lo sviluppatore JavaGuru che fa parte del team di BestJavaProgrammer vuole collaborare allo sviluppo di TeamWork, per cui apre la sua brava shell (JavaGuru, onorando il suo nome, usa sistemi operativi che hanno una vera e completa shell a linea di comando!) e digita:

git clone prot://path.to.git [my_dir]

dove my_dir è opzionale ed indica la volontà di JavaGuru di cambiare il nome della directory principale del progetto da teamwork a my_dir (ciò non ha ovviamente alcun effetto sul progetto di BestJavaProgrammer).

L’esecuzione del comando comporta la creazione in locale di una cartella teamwork (o my_dir) che costituisce una copia completa del repository di BestJavaProgrammer (completa = files di progetto più file con la storia completa del repository).
In altre parole ora JavaGuru ha in locale un suo repository nuovo e completo di tutto.
Git terrà una informazione supplementare su questa copia che gli permette di sapere qual’è il repository remoto da cui è stato effettuato il comando di clone.

JavaGuru produce!

JavaGuru lavora sul progetto appena scaricato in modo alacre e brillante.
Dopo qualche ora ha già cambiato tutto o quasi.
Per esaminare le modifiche effettuate esegue il comando:

git status

Se vuole sapere in dettaglio cosa ha cambiato sul file “numero-primo.txt” esegue:

git diff numero-primo.txt

Quindi sicuro delle modifiche effettuate le committa, aggiungendo anche automaticamente i nuovi files creati con:

git commit -a -m "log di info su quello che ho fatto"

Quindi JavaGuru parla con BestJavaProgrammer delle spettacolari implementazioni fatte e lo invita ad aggiornare il proprio progetto. BestJavaProgrammer lo fa ma… non cambia nulla.
BestJavaProgrammer non vede lo spettacolo tanto decantato da JavaGuru! Perchè?

Semplice: con git, tutte le operazioni “classiche” di commit, ma anche branch, etc… sono sempre locali al proprio repository. Ricordate cosa fa il comando git clone?
JavaGuru ha un repository locale e tutte le operazioni standard sono sempre e solo riferite a questo.

JavaGuru condivide!

A questo punto JavaGuru, che fino ad ora era un Guru di java ma non di Git, capisce che deve fare un’operazione ulteriore per comunicare a BestJavaProgrammer le sue fantasmagoriche modifiche.

La “semplice” operazione da fare è la seguente:

git push

Con questo comando JavaGuru “spinge” all’amico le sue modifiche

JavaGuru si aggiorna!

E se poi è BestJavaProgrammer a fare delle modifiche? A questo punto il concetto è semplice: JavaGuru dovrà “tirare” a sè le modifiche dell’amico con:

git pull

Quelle descritte sono le operazioni più semplici previste per un uso in team di git.
Con l’introduzione dei branch e le fusioni le cose si complicano un pochino, ma saranno oggetto di altri articoli.