L’ultima release di Eclipse (la Indigo) è favolosa. A prima vista non sembra molto diversa dalle precedenti ma la reattività e la stabilità è notevolmente aumentata. Funziona così bene che ho ricominciato ad usarla dimenticandomi dei problemi che mi aveva dato Helios.

La prima cosa che ho cercato era l’integrazione con Git (si, sono innamorato).

Bene, la ricerca è stata breve e il risultato è molto soddisfacente: EGit. L’ultima versione di Eclipse include questo plugin nella vasta gamma dei plugin scaricabili.

Quindi:

• Andate in Help -> Install New Software...
• Cercate egit e installatelo.
• Riavviate Eclipse
• A questo punto andate su un vostro progetto e cliccando con il destro andate su Team -> Share…
• Scegliete Git come sistema di CVS.
• Il programma vi chiederà dove creare il repository. Per non confondervi scegliete di creare il repository in una sub-directory del progetto (.git) selezionando la relativa spunta. Questo vi eviterà problemi nell’uso di tools esterni.

A questo punto tutto è pronto per il primo commit. Possiamo fare tutto da Eclipse.

• Andate in Team -> Commit… e selezionate tutti i file da aggiungere.
• Effettuate il commit.

Egit offre un ottima integrazione con Git con tanto di rappresentazione grafica della storia, dei rami, delle versioni e di tutte le altre funzioni di Git (compreso il rebase, il merge e il cherry-picking).

Insomma, se utilizzate Eclipse ve lo consiglio caldamente.

Oggi dovevo scrivere una guida che rendesse persone digiune di git capaci di gestire un progetto multi utente distribuito. Non so se sono riuscito nell’interno ma dato che ci ho messo due ore per scrivere queste 6-7 pagine di documentazione vorrei condividerla con tutti.

L’ho scritta di fretta, alcune informazioni sono carenti e altre mancanti, ma credo che nel complesso sia uscita una cosa molto carina e istruttiva. Quantomeno, dopo aver letto questa guida, saprete dove mettere le mani per fare qualcosa. Penso che la aggiornerò ancora nei prossimi giorni quindi magari ripassateci.

Eccola qui:

GUIDA MEGAGALATTICA EXPRESS PER GIT

EDIT 13-07-2011: Ieri sera ho riletto tutta la guida e ho corretto alcune imprecisioni, oltre ad aver sistemato qualche carenza stilistica e grafica. Vi ricordo che suggerimenti e commenti sono molto apprezzati!

Git non è l’unico sistema di controllo di versione esistente (aimè! xD). Ad esempio SVN è il sistema utilizzato ufficialmente dal progetto KDE (anche se c’è l’intenzione di passare a Git nel prossimo futuro). A questo punto sorge spontaneo chiedersi come si possa fare per partecipare a questi progetti ma, allo stesso tempo, continuare ad utilizzare il nostro (mio) amato Git?

La soluzione, ovviamente, esiste. Basta installare il pacchetto git-svn che offre un comodo layer di interfaccia fra Git e Svn. Ma vediamo come usarlo:

La prima cosa da fare è di clonare il repository svn. Questo può essere fatto semplicemente con il comando:

git svn clone  ?optional-directory-name?

Lo svantaggio di questa operazione è data però dalla lentezza. Questo perché la cronologia di git viene riempita scaricando dal repo svn ogni commit singolarmente. Quindi è meglio che eseguiate questo comando solamente quando avete un po’ di tempo da perdere.

Il prossimo comando serve a tenere aggiornata la nostra copia locale rispetto al trunk remoto. Il corrispettivo, in pratica, del comando svn update.

git svn rebase

Per ultimo, vediamo invece come inviare il nostro ramo locale nel ramo remoto:

git svn dcommit

Per tutto il resto del tempo potete continuare ad utilizzare i classici comandi git, potete creare rami locali, riunirli, fare tutto ciò che vi pare come se il progetto fosse nativamente gestito da git.

Un vantaggio niente male eh?

Come spero sappiate amo Git con tutto il mio cuore. Volevo quindi appuntare una serie di configurazioni che trovo utilissime. Una piccola nota nel caso vi dimentichiate alcuni pezzi di sintassi (e io lo dimentico spesso).

1 – UTENTE

Inserire l’utente è fondamentale per fare in modo che i commit non escano con nomi casuali e irriconoscibili.

git config --global user.name "Il vostro nome"

git config --global user.email tuaemail@dominio.it

2 – COLORI

Per migliorare la leggibilità è cosa buona e giusta abilitare i colori nell’output dei comandi di git.

git config --global color.branch auto

git config --global color.diff auto

git config --global color.interactive auto

git config --global color.status auto

3 – MERGE

Prima cosa da fare è configurare lo strumento che useremo per risolvere i conflitti del merge. Io su KDE uso kdiff3 ma per GNOME esiste un alternativa altrettanto valida di nome meld.

Per Kdiff3 bisogna però aggiungere una configurazione ulteriore. Andate a Settings, Configure KDiff3, Integration. Nella casella ‘Command line options to ignore’, aggiungete il parametro ‘;–’.

A questo punto vi basta configurare git.

git config --global merge.tool kdiff3

4 – EDITOR

Potete anche configurare l’editor che git userà quando avrà bisogno di farvi editare del testo.

git config --global core.editor vim

Potete sceglierne anche uno con interfaccia grafica.

So che lo state pensando. “Oh no! Un altra GUI per Git! Che dio ci scampi!”. Effettivamente di gui per git ce ne sono a valanghe. Ognuna con i suoi vantaggi e svantaggi. Però Gitg ha qualcosa che te la fa preferire. Innanzitutto è ben integrato con GNOME, secondo ha una velocità impressionante nel caricare repository di enormi dimensioni (dall’immagine potete vedere che carica più di 17.000 commit in meno di un secondo).

E poi è graficamente gradevole con i suoi colori e amenità varie. E questo non guasta mai.

Il programma è disponibile nei repo ufficiali di Lucid ma vi consiglio di usare la versione 0.0.6 che invece trovate nei repo di Maverik. Potete prenderla direttamente da la, non ci sono problemi.

Unica pecca il supporto ai repository remoti non ancora completo.

Se vi capita provatelo. Buon sabato.

Abbiamo visto in qualche articolo precedente come utilizare Bazaar, il CVS di Launchpad, per gestire il nostro codice e upparlo sul server remoto. All’epoca però avevo volutamente tralasciato due punti per questioni di spazio: come creare un progetto su Launchpad e, soprattutto, come gestirlo fra più utenti. Due cose che, per chi usa Bazaar per piccoli progetti personali, non hanno molta importanza ma diventano indispensabili per chi vuole sviluppare un progetto in collaborazione con più persone.

La prima cosa da fare è sicuramente registrarsi su Launchpad. La registrazione è molto semplice e non penso necessiti di ulteriori spiegazioni.

Una volta che abbiamo il nostro utente è necessario configurare una chiave RSA per il collegamento sicuro SSH. Per fare questo dobbiamo aprire il terminale e digitare:

$ ssh-keygen

E seguire le istruzioni. Una volta completato avremo il file id_rsa.pub con la nostra chiave pubblica nella cartella .ssh all’interno della nostra Home. Fatto questo andiamo sul nostro profilo in Launchpad, individuiamo la voce SSH Keys e clicchiamo sul bollino giallo a fianco. Noterete una casella di testo piuttosto grande: copiate lì il contenuto del file id_rsa.pub e data infine Import Public Key.

Ora siete pronti per creare il progetto. Anche qui la procedura è semplice: dalla Home Page di Launchpad, sotto Get Started, troverete il link per Create new project. Cliccateci sopra ed inserite le informazioniche vichiede, sono tutte molto ovvie, nome, descrizione del progetto, url e via dicendo.

Avrete a disposizione ora la nuova pagina per il vostro progetto.

La prima cosa da fare è creare una series. Una serie non è altro che una “corrente” di sviluppo. Progetti complessi hanno solitamente più series: la trunk che contiene gli ultimi sviluppi, una series per laversione 0.5, una series per la versione 0.6 e così via. All’inizio vi conviene partire con la serie base, la trunk. Createla.

Una volta creata la serie dovete creare un branches o ramo. I rami corrispondono a vari percorsi di sviluppo all’interno della stessa serie. Se le series indicano qual’è il fine di un percorso di sviluppo, i branches rappresentano le varie strade che conducono a tale fine. Infatti, solitamente , tutti i rami di una serie, alla fine del ciclo di sviluppo, o vengono eliminati o si riuniscono nella cosiddetta versione “stable”.

Creato il vostro ramo (che solitamente essendo il principale si chiama, con molta fantasia, main) potete uppare il vostro progetto con bazaar come spiegato nell’apposita guida. In generale basta il comando:

$ bzr push lp:~userid/project-name/branch-name

Se non sapete come usare bazaar datevi una letta alla pratica guida.

Ora è il momento di scegliere come far collaborare il gruppo al progetto. Esistono infatti 3 approcci differenti:

• Centralizzato: Tutti i membri del gruppo inviano i propri commit direttamente sul server remoto (meccanismo di Subversion).
• Centralizzato con commit locali: Ogni membro commissiona alcuni commit locali e, quando è pronto, invia sul server remoto tutti i commit in un solo colpo (meccanismo di Git).
• Decentralizzato con guida condivisa: Ogni utente ha il proprio ramo di sviluppo che all’occorrenza viene “fuso” con un ramo principale (main).

In questa guida spiegherò il meccanismo più semplice e intuitivo. Il centralizzato.

Il meccanismo centralizzato è il più semplice ma anche il più rigido dei meccanismi. Si adatta bene a gruppi non molto numerosi e che possono facilmente tenersi in contatto. In gruppi troppo numerosi infatti la possibilità di conflitti cresce esponenzialmente.

Per spiegare questo meccanismo supponiamo che ci sia un gruppo di sviluppo composto da tre utenti: L, Q e H. (messaggio subliminale).

• I tre membri creano un team, che si chiama casualmente proprio LQH, cliccando l’apposito link nell’home di Launchpad (non penso sia complicato ma se avete difficoltà ditemelo che aggiungerò questa parte).
• Tutti e tre i membri devono effettuare il checkout del progetto. Per fare ciò si aprono il terminale nella cartella dei loro progetti e digitano:
   $ bzr checkout lp:team-name/project-name/branch-name
• L decide di effettuare alcune modifiche al codice. Le fa tranquillamente e alla fine commissiona con
  $ bzr commit -m "Messaggio"
• Q e H a questo punto possono aggiornare la loro cartella con
  $ bzr update
• Se Q o H avessero fatto modifiche al codice prima dell’update le due verisone verrebbero “fuse”. Nonostante  ciò è possibile che si verifichino dei conflitti. Questi vanno risolti (spesso a mano) prima di effettuare nuovamente l’update.

Questo è il meccanismo base con il quale potete organizzare un progetto su Launchpad con Bazaar. Ovviamente ci sono piccoli trucchi che imparerete col tempo che miglioreranno la vostra produttività.

Qui mi sono già dilungato troppo. Se ci sono problemi tornerò volentieri sull’argomento.

Dopo aver visto a grandi linee come funziona Git adesso ci occupiamo di quello che reputo il più agguerrito concorrente di Git: Bazaar. Bazaar ha un vantaggio fondamentale: è supportato da Launchpad, la migliore e la più completa piattaforma di project-hosting a mio avviso. Contro bazaar pendono soprattutto due critiche: bazaar è mediamente più lento di Git e più insicuro in quanto l’algoritmo crittografico di Git è praticamente inviolabile mentre bazaar è leggermente meno sicuro.

Ciò non toglie che per quei progetti che non siano immensi le differenze sono trascurabili.

Vediamo come utilizzare bazaar:

Innanzitutto dobbiamo presentarci. Per fare questo utilizziamo i comandi:

$ bzr whoami "Bill Gates <ilovemac@gmail.com>"

Una volta fatto ciò andiamo nella cartella del nostro progetto e diamo:

$ bzr init
$ bzr add

In questo modo tutta la cartella verrà ricorsivamente aggiunta al sistema. Confermiamo con:

$ bzr commit -m "First commit"

Adesso si può inviare il progetto su launchpad con:

$ bzr push bzr+ssh://bill.gates@bazaar.launchpad.net/~bill.gates/+junk/myproject

Come avete visto bazaar è leggermente più intuitivo e permette un più facile management.

Con questi pochi semplici comandi potete già cominciare a lavorare.

Quello che personalmente mi mancha è una gui potente come quella di Git. Ma vedrò di fare qualche ricerca.

Dopo aver visto un po di comandi base di Git è giunto il momento di vedere un tool molto semplice per avere tutta la storia del progetto a portata di click.

Gitk è un tool grafico scritto con le librerie Tk per interagire con Git. Permette di navigare con facilità attraverso i vari commit e i vari rami del progetto. Possiamo installarlo facilmente con:

# apt-get install gitk
# apt-get install git-gui

Una volta installato basta spostarci nella cartella del programma e dare:

$ gitk

A questo punto ci apparirà una finestra simile a quella mostrata nello screenshot.

Nella finestra possiamo identificare subito 3 zone:

• La finestra del grafo. In alto. Qui sono mostrati i vari commit con la loro descrizione. A sinistra di c’è la rappresentazione grafica dei vari rami. Delle linee che mostrano la storia del progetto, le divisioni e le riunificazioni dei vari rami. Così che si possa facilmente capire come si distribuiscono le varie linee di progetto.
• La finestra dei diff. A sinistra. Qui, per ogni commit, vengono mostrate in dettaglio le differenza fra la versione attuale e quella precedente.
• La finestra dei file. Dove vengono mostrati, per ogni commit, i file interessati da modifiche.

Ma la caratteristica principale è nascosta nel menù file. Da qui infatti possiamo avviare git-gui (tramite Start git gui).

Git-Gui è il tool per eccellenza. Ci permetti di fare per via grafica gran parte delle operazioni di Git. Possiamo creare branches, fare merge, commit, push, possiamo comprimere il database per aumentre le prestazioni, possiamo vedere quali file sono stati modificati ma non ancora commissionati e gestire i repository remoti (come Gitorious).

Insomma, abbiamo a disposizione un tool molto potente, leggero e versatile per poter dimenticare il terminale in quasi tutti i casi di utilità. Resta il fatto che i comandi da terminale è sempre meglio saperli.

Vi consiglio vivamente di provarlo.

Alla prossima.

Continuiamo a parlare di Git. Dopo aver visto come inizializzare un progetto e gestire le varie modifiche semplicemente con git-add e git-commit, vediamo come ottenere la lista delle varie modifiche e come gestire i vari rami di sviluppo.

Innanzitutto affrontiamo la questione dei log. I log sono dei riassunti in cui sono elencati via via tutti i vari commit che sono stati inviati. Git permette di creare un gran numero di log con un enorme lista di opzioni. Io presenterò solo le tre forme più diffuse lasciandovi, per il momento, il divertimento di legger man git-log per vedere in dettaglio tutte le varie opzioni.

Il log più semplice è sicuramente

$ git log

Con questo comando otterrete semplicemente la lista di tutti i commit con data e autore.

Se invece volete sapere, per ogni commit, anche quali modifiche siano state effettuate vi basta digitare:

$ git log -p

In questo modo alla lista precedente verrà aggiunto anche il diff corrispondente ovvero una lista dettagliata della modifica effettuata.

Spesso però la lista dettagliata non interessa, ma interessa soltanto un riassunto che ci dica l’entità delle modifiche effettuate su ogni file.

$ git log --stat --summary

Questo comando mostra, per ogni commit, quante righe sono state modificate/aggiunte/rimosse per ogni file.

Ora vediamo invece come gestire i vari rami di sviluppo.

Supponiamo di voler creare un ramo sperimentale per la nostra applicazione. Per creare questo ramo ci basta digitare:

$ git branch experimental

Ora il nostro ramo è stato creato e per apportargli modifiche ci basta dare

$ git checkout experimental

Ora siamo nel ramo experimental. Possiamo modificare liberamente i nostri file e, dopo aver modificato a piacere, tornare di nuovo al ramo principale con

$ git checkout master

Noterete che le modifiche appena fatte non sono più visibili. Esse infatti sono state fatte nel ramo experimental. Ora potete fare delle modifiche diverse nel ramo “master” causando così la separazione dei due rami.

A questo punto potreste voler riunire di nuovo i due rami perché avete visto che la modifica in experimental funziona meglio della versione originale. Per fare ciò basta un semplicissimo

$ git merge experimental

E, se non ci sono conflitti, avete concluso. In caso di conflitti invece le righe conflittuali verranno marcate così da semplificare la loro adeguazione.

Ora non vi resta che cancellare il ramo experimental, se non vi serve più, con

$ git branch -d experimental

Come vedete la gestione dei rami è decisamente semplice e vi permette in modo rapido e sicuro di azzardare modifiche al codice mantenendo sempre una versione stabile su cui appoggiarvi.

Ovviamente potete mantenere contemporaneamente qualunque numero di branches vogliate.

Hai richieste al riguardo? Commenta o visita il forum!

Precedentemente abbiamo visto come muovere i primi passi con Git. Ovviamente usare un CVS in locale non sfrutta le sue massime potenzialità.

Dobbiamo quindi trovare un host remoto sul quale condividere il progetto. Quello che uso io è Gitorious. Gitorious offre hosting gratuito per tutti quei progetti con licenze riconosciute dalla Free Software Foundation. Se avete bisogno di hosting per software closed, oltre a non avere la mia stima, dovrete ricorrere a hosting a pagamento (basta una rapida ricerca su Google).

Per prima cosa dobbiamo registrarci. La procedura è semplice e non richiede nessuna conoscenza particolare. Dopodiché creiamo un nuovo progetto cliccando sul bottone in fondo a destra.

Dopo aver inserito i dati del progetto vi verrà chiesto di inserire la vostra chiave SSH pubblica per garantire la massima sicurezza. Se non avete una chiave ssh è il momento di crearne una con il comando:

$ ssh-keygen

Vi verrà chiesto di inserire la password. Inseritela e al termine della procedura avrete la vostra chiave nel file .ssh/id_rsa.pub nella vostra home.

Ora potete aprire questo file e copiarne il contenuto per inserirlo in Gitorious e fargli accettare questa chiave.

Subito dopo dovrete creare il primo repository del vostro progetto. Un repository non è altro che uno scaffale che contiente il vostro codice. In progetti complessi potreste aver bisogno di mantenere contemporaneamente più versioni del vostro programma (ad esempio risolvendo bug della versione stable e intanto preparare la nuova versione). In questo caso vi basterà creare due repository, uno per la versione stable (es: pippo2.0) e un altro per la versione di sviluppo (es: trunk).

A voi però per il momento ne basta uno. Createlo seguendo le indicazioni e avrete finito.

Ora dovete configurare git affinché riconosca il repository remoto appena creato.

Aprite il file .git/config nella cartella del vostro progetto e inserite come segue:

[remote "origin"]
       url = git@gitorious.org:project/repository.git
       fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
       remote = origin
       merge = refs/heads/master

Sostituendo a project il nome del progetto su Gitorious, e a repository il nome del repository. Questa configurazione istruisce git dicendogli che il branch locale master ha il suo corrispettivo remoto origin.

A questo punto per spedire il vostro progetto nella rete non basta che dare:

$ git push

E godersi l’idea che il proprio progetto fa ora parte del fantastico mondo del Free Software.