Breve guida all’utilizzo di Git alla maniera di CVS su piattaforma Windows (XP Pro in questo caso), ovvero la sintesi del peggio.

Scenario

Due sviluppatori decidono di collaborare ad un progetto Java, si tratta di:

Gino – sviluppatore Java, lavora su Windows

Lino – sviluppatore tuttofare, lavora su Mac Os X

Lino possiede una macchina CentOS su cui gira un server SVN a casa propria, il tutto funziona bene ma Lino si annoia e spiana la macchina per effettuare alcuni esperimenti. Nel frattempo accade nell’ordine che:

L’esigenza di avere un repository comune per i sorgenti del progetto si fa incalzante Git diventa famoso GitHub apre i battenti

Il resto è storia…

Step 1 – account su GitHub

E’ la parte più facile, Lino va su http://github.com e registra un account, per ora si accontenta di quello gratuito, che se da un lato non offre la possibilità di avere repository privati, dall’altro è completo in termini di funzionalità a meno del servizio SSL (ma visto che il repository è comunque pubblico…).

Step 2 – setup di msysgit su Winbloze

La fama di Git è letteralmente esplosa e il supporto per Windows non ha tenuto il passo. Fortunatamente dei ragazzi volenterosi hanno messo insieme un pacchetto di installazione a partire da materiale esistente: msysgit. Una volta installato, Lino ha a disposizione una shell Unixlike con git 1.5.5 già configurato, ssh e chicche varie. Ci sarebbe anche una GUI Tcl ma Lino non è riuscito a farla funzionare. Per evitare che i logs relativi ai suoi commit su GitHub siano attribuiti all’utente unknown, Lino indica a git il suo username; dalla shell di msysgit, al prompt digita

$ git config --global user.name "lino" $ git config --global user.email lino@example.com

Step 3 – setup delle chiavi ssh

Chi come Lino non ha una coppia di chiavi ssh (!!!) può generarle usando proprio msysgit. Dal menu Start -> Programmi -> Git selezionare la voce Git, si apre una finestra contente la shell; al prompt digitare

ssh-keygen -C “username@email.com” -t rsa

Lino fornisce una password ed accetta le opzioni che il programma suggerisce per il nome e la destinazione dei due files contenenti le chiavi, che finiranno in ~/.ssh/ che tradotto nel path NTFS diventa C:\Documents and Settings\Lino\.ssh. Successivamente bisogna fornire la chiave pubblica a GitHub: basta fare login, editare il proprio account (in alto a destra) e copiare ed incollare il contenuto della chiave pubblica (che è stato salvato in ~/.ssh/id_rsa.pub) nell’apposito box.

Step 4 – Creazione del repository

Ovviamente se il repository già esiste questo step è superfluo. Basta avviare la procedura a questo link: http://github.com/repositories/new e digitare i comandi suggeriti nella shell di msysgit.

Step 5 – Clone del repository (era: cvs checkout)

Per iniziare a lavorare sul repository remoto bisogna effettuare quello che con CVS avremmo chiamato checkout: il clone del repository. Nel pannello di controllo di GitHub, fra i dettagli del proprio progetto, Lino trova il seguente:

Public Clone URL: git://github.com/lino/progettox.git

Dalla shell di msysgit Lino punta sulla cartella di lavoro che conterrà il progetto e poi esegue il cosiddetto clone:

$ git clone git://github.com/lino/progettox.git ProgettoX

Se tutto va bene ora nella cartella di lavoro dovrebbe esserci una nuova cartella chiamata ProgettoX contenente i sorgenti. Siamo operativi, Lino può festeggiare e cominciare ad usare Git proprio come faceva con CVS…

Push delle modifiche (era: cvs commit)

Lino modifica alcuni files nel repository locale clonato da quello su github; per spedire le modifiche sul repository remoto esegue il cosiddetto push. Per prima cosa, Lino esegue un commit locale, come farebbe con CVS:

$ git commit -m"messaggio di commit"

In seguito, come per il link del clone, Lino recupera da GitHub il push url. Poi, dalla cartella ProgettoX:

$ git push git://github.com/lino/progettox.git

Pull delle modifiche (era: cvs update)

Gino ha già fatto il clone del repository su GitHub, per recuperare le ultime modifiche di Lino al progetto esegue il pull:

$ git pull

Considerazioni

L’utilizzo di Git alla maniera di CVS consente agli sviluppatori di cambiare sistema di SCM con il minor sforzo mentale possibile ma, come ci si può aspettare, utilizzare git in questo modo è un po’ uno spreco… Git ha l’enorme vantaggio di essere un sistema distribuito, perciò ogni repository locale è un’entità autonoma rispetto al progetto complessivo, vale a dire che Lino può branchare localmente il repository, effettuare delle modifiche per conto suo, tornare sulla master branch (la CVS HEAD) quando collabora col team e ancora ritornare sulla propria branch nel tempo libero. Quando pronto potrà fare un merge della branch locale sulla master locale, e solo successivamente fare il push sul repository remoto… e questo è solo per fare un esempio, le possibilità sono veramente tante!

Riferimenti

Questo post è il risultato di un meshup di articoli e guide che ho letto per far utilizzare GitHub ad un collega Windows-user, di seguito gli originali:

Git Introduction Tutorial

(http://www.kernel.org/pub/software/scm/git/docs/tutorial.html)

Git for CVS users

(http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html)

Providing your SSH key

(http://github.com/guides/providing-your-ssh-key)