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.

Stavo attrezzando un piccolo progettino scemo sulle OpenGL (più didattico che altro) e così ho pensato di condividere quelle regole non scritte che servono ad organizzare e gestire un progetto software. Sono piccole “tips”, struttura delle cartelle e file che non devono mai mancare. Presenterò anche altri strumenti, come ho fatto per Python, ma questa volta saranno strumenti “generici”, ovvero utilizzabili con qualunque linguaggio.

Questo perché tenere in piedi un progetto male organizzato è come costruire un castello di carta. Ci vuole una base forte per rendere il più accogliente possibile il progetto per le persone interessate a collaborare, sia per i membri del vostro team (se ne avete uno).

STRUTTURA CARTELLE

Le cartelle vanno organizzate in modo piuttosto coerente. È importante non mischiare tutto in poche cartelle confuse specialmente per progetti destinati a crescere rapidamente. Una struttura minimale è la seguente:

• src – La cartella src contiene il codice sorgente. Il codice al suo interno può essere organizzato come si desidera in accordo con le convenzioni del linguaggio. L’importante è che contenga solamente il codice del programma/libreria.
• test – La cartella test contiene il codice sorgente dedicato ai test. Il codice di test serve a provare il corretto funzionamento delle classi sviluppate o di alcuni moduli software oppure possono essere semplicemente test prestazionali.
• build – La cartella build contiene tutti i file ottenuti come residuo di una compilazione. Possono essere moduli parziali C/C++ (.o), classi Java (.class), file python compilati (.pyc) e così via. La cartella va a sua volta divisa nelle varie configurazioni di compilazione (ad esempio ci potrebbe essere una configurazione Debug con compilati ottimizzati per il debug e una configurazione Release con compilati ottimizzati per le prestazioni).
• dist – La cartella dist contiene il prodotto finito. Può essere il programma eseguibile, un file .jar, una libreria .so e così via. Tutto quello che sta in dist deve essere pronto per essere eseguito e distribuito.
• doc – La cartella doc contiene la documentazione dettagliata. Tale documentazione è per lo più la specifica dettagliata delle API la quale è solitamente auto-generata.

FILE MUST

Nella cartella radice sono necessari alcuni file. Necessari è una parola grossa in quanto solitamente il programma funziona benissimo anche senza, ma sono un tocco di classe e di umanità verso chi vuole accedere ai sorgenti della vostra applicazione.

• Tool di compilazione - Sia Makefile, o Cmake o qualunque altro tool utilizzate… DEVE esserci uno strumento per la configurazione e la compilazione. Molti IDE possono anche auto-generare roba simile.
• README – Il readme deve dire vita morte e miracoli sull’applicazione. Deve spiegare come può essere compilata  l’applicazione, quali sono le dipendenze, i bug noti, etc..
• README.src – Per applicazioni il cui README è eccessivamente complesso è bene separare le informazioni per sviluppatori in un file a parte. Il file README.src deve spiegare come è organizzato il codice, quale IDE si è usato (se si è usato), quale librerie di sviluppo servono, quale strumenti si sono usati per generare la documentazione, per i test e per altro. Insomma… tutto ciò che può essere utile per chi è interessato alla modifica del codice.
• COPYRIGTH - Il file che contiene le informazioni sulla licenza del progetto.
• CHANGELOG – Il file che contiene la lista dei cambiamenti apportati al programma nel corso della sua storia. Questo file può essere auto-generato da alcuni sistemi di CVS.

DOCUMENTAZIONE

Scrivere a mano la documentazione è sempre l’ultimo dei problemi. Nonostante ci siano molte cose che debbano necessariamente essere scritte a mano, per le API è possibile usare dei tools automatici. Abbiamo visto Epydoc per python. Bene, per tutto il resto c’è Doxygen. Doxygen è un programma di auto-generazione della documentazione utilizzabile per una miriade di linguaggi.

CVS

Il programma per CVS è essenziale se programmate in gruppo ma è molto utile anche se programmate da soli. Vi permette di manipolare il codice con molta disinvoltura navigando fra branch diversi in modo del tutto trasparente.

Potete usare quello che vi pare come CVS anche se io consiglio sempre GIT. Lo trovo molto più veloce ed elastico dei concorrenti. Se volete convincervi potete sempre andare su http://it.whygitisbetterthanx.com/

MESSAGGISTICA

Ebbene si. Se avete un gruppo di persone con cui lavorate insieme non potete prescindere da un sistema rapido e veloce per lo scambio di informazioni, siano esse “OMG! Non funziona una cippa!” o messaggi più tecnici.

A questo punto avete le basi. Non vi resta che seguire questi consigli e lanciarvi nel tempestoso mondo del software libero sperando che il vostro progetto non sia un castello di carte spazzato via dal vento.

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.

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.

Git è un importante e noto version control system. Utilizzato dagli stessi sviluppatori del kernel, nonchè dagli sviluppatori di progetti come Qt e KDE.
Ha l’enorme pregio della velocità ed è possibile trovare molti tools di supporto e hosting gratuiti (io utilizzo Gitorious).

Adesso vedremo un piccolo quick start, ovvero una piccola guida per conoscere le basi di Git ed essere subito operativi. La guida è basata sull’ultima versione disponibile al momento (la 1.6.4.1) ma dovrebbe adattarsi facilmente anche a versioni non troppo distanti.

Per prima cosa installiamo Git con il solito comando:

# apt-get install git-core

Facendolo precedere da sudo se usate ubuntu e derivate.

Una volta installato dobbiamo procedere alla configurazione iniziale:

$ git config --global user.name "Qui Inserisci Il Tuo Nome"
$ git config --global user.email qui.inserisci@la.tua.email

Ora siamo pronti ad inizializzare Git con il progetto che stiamo portando avanti. Supponiamo che il progetto si trovi in una cartella project nella vostra home.

$ cd project
$ git init
$ git add .

Il comando init inizializzerà Git e creerà una cartella nascosta .git/ in cui verranno memorizzati i dati. Il comando add, invece, aggiungerà i file a del progetto nell’insieme dei file controllati da Git. Ora, per rendere effettivo tutto basta dare:

$ git commit

Vi verrà chiesto di inserire un messaggio che descriva il commit, ovvero che spieghi a grandi linee cosa è stato modificato-aggiunto dall’ultima volta.

Ora potete bellamente modificare tutto e Git terrà traccia di tali modifiche. Per vedere un breve riassunto dei file modificati dall’ultimo commit basta dare

$ git status

Che restituirà una lista del tipo:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   file1
#       modified:   file2
#       modified:   file3

Queste sono grossomodo le basi. Successivamente vedremo come hostare un progetto mantenuto con git in Gitorious e come gestire le varie branch.