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? ;)

 

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/ :D

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. :D

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.

 

LaunchpadAbbiamo 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!
Serve aiuto? LQH!

 

GitoriousPrecedentemente 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.

© 2008-2012 SlashCode Suffusion theme by Sayontan Sinha