Creare un server Git su Raspberry Pi

Di - 2 May 2014 - in
Post image for Creare un server Git su Raspberry Pi

Cos’è Git

Chiunque gestisca progetti di qualunque tipo, sa bene quanto possa essere utile mantenere memorizzate da qualche parte le diverse versioni del lavoro, in modo da potere in qualunque momento tornare indietro e annullare una o più modifiche.

Per farlo, spesso, si salvano più copie dello stesso file, magari numerate e magari cercando di tenerle bene in ordine, ma sempre con il risultato di avere qualcosa che, al momento del bisogno, risulta essere inservibile.

Esistono, però, diversi software che aiutano molto in questo processo e che, anche se nati nell’ambito della gestione di progetti software, possono essere comodi per gestire qualunque altra cosa (pur cavandosela molto meglio con i file di testo che con i file binari, per ovvi motivi tecnici). Nella storia, un po’ per moda e un po’ per necessità tecniche, si sono avvicendati diversi programmi con diversi metodi, da CVS, abbastanza macchinoso, a Subversion che ne è la naturale evoluzione, fino a Git (si pronuncia ghit), che è uno dei più utilizzati al momento.

Git, sviluppato inizialmente da Linus Torvalds per gestire il versionamento del kernel di Linux (prima gli sviluppatori si appoggiavano a BitKeeper, che è poi diventato a pagamento), è un sistema molto interessante e molto diverso dai suoi predecessori nel mondo Open Source.

CVS e Subversion, infatti, sono basati sull’idea di avere un server centrale, chiamato repository che mantenesse tutte le versioni di ogni file del progetto. Chiunque volesse modificare un file, deve, tramite un’operazione detta commit, registrare il file modificato sul server, eventualmente gestendo conflitti se più utenti modificano lo stesso file.

Git è invece un sistema molto più distribuito. Ogni utente ha il suo repository locale, da modificare e su cui fare i commit, per poi, tramite operazioni di push e di pull gestire la sincronizzazione con i repository delle altre persone che lavorano allo stesso progetto, sempre con la necessità di gestire eventuali conflitti. Nella realtà, l’architettura più diffusa consiste nell’avere comunque un server centrale che faccia da repository principale, con tutti i repository dei singoli utenti che si sincronizzano solo con quello.

Un’architettura distribuita ha grandi vantaggi di praticità, primo fra tutti il fatto di non rendere necessario di essere online mentre si lavora. Si possono continuare a fare commit offline sul proprio repository locale, per poi sincronizzarsi con il repository centrale solo quando necessario. Un altro enorme vantaggio è legato alla possibilità, in Git, di creare dei fork, ovvero delle diramazioni dal progetto principale (ad esempio, in un software, se voglio implementare una funzionalità nuova, posso fare un fork dal progetto principale, su cui continuo a lavorare separatamente, per poi fondere il fork col progetto quando sarà pronto). Tale possibilità esiste anche sugli altri sistemi di versionamento, ma Git permette a ogni collaboratore, o gruppo di collaboratori, di gestirsi come preferisce i suoi eventuali fork, senza che questi siano necessariamente registrati sul server principale.

In Git, come in genere negli altri sistemi, ogni commit ha un suo identificativo, ed è quindi possibile richiedere al sistema lo stato del progetto al momento di qualunque commt passato, fornendo così un sistema di versionamento ordinato, pulito e molto pratico da utilizzare.

Non posso spiegare qui nel dettaglio il funzionamento di Git, ma sperando di aver fatto venire un minimo di curiosità, vi rimando all’ottimo manuale ufficiale, che contiene anche, in termini più generali, la guida che segue.

Perché Raspberry Pi

Trovo che, per un uso casalingo, Raspberry Pi possa fare un ottimo lavoro come server Git centrale, a cui riferirsi lavorando sul proprio PC con un repository locale. In questo modo, rispetto al lavorare solo in locale, si guadagna la possibilità di lavorare allo stesso progetto da più PC o in più persone, assieme ad un vero e proprio backup del progetto (e di tutte le sue versioni!) sulla Raspberry Pi.

Con il suo non occupare spazio, non fare rumore e non consumare troppa corrente, difficilmente si riesce ad immaginare uno strumento migliore della Raspberry Pi per questo compito.

Ovviamente si può pensare anche ad un repository accessibile anche da fuori casa/ufficio, ma in questa guida non coprirò una situazione simile né dal punto di vista della sicurezza (accesso ssh via chiave) né dal punto di vista della configurazione del router (che varia da router a router).

Cosa ci serve e come configurarlo

La configurazione necessaria per utilizzare a questo scopo una Raspberry Pi è quella tipica necessaria per l’utilizzo della Raspberry Pi come macchina headless.  Questo tipo di configurazione è descritta dettagliatamente nella prima parte della nostra guida Creare un nodo Bittorrent con una Raspberry Pi, a cui vi rimando. Per l’utilizzo di Git è necessario conoscere i comandi di base (creazione file, cambio di directory…) sul terminale del sistema operativo che utilizzerete come client.

Installazione e configurazione di Git

A questo punto, rimane soltanto da installare Git. Il software è presente nella distribuzione Raspbian, quindi basterà dare il comando

sudo apt-get install git-core

Per motivi di sicurezza e semplicità, è bene che i repository Git appartengano ad un apposito utente, che chiamiamo git. Tale utente avrà come home personale, che è poi la directory dove andranno i repository, /mnt/disco/git (assumendo che /mnt/disco sia la directory sulla quale è montato il disco esterno).

Creiamo l’utente (e il relativo gruppo):

adduser --system --shell /bin/bash --gecos 'git version control by pi' --group --home /mnt/disco/git git

E diamogli una password:

passwd git

Git è, a questo punto, praticamente pronto a partire.

Creare un repository

Siamo dunque pronti a creare il nostro primissimo repository. Esistono due tipi di repository Git: quelli semplici, che contengono i file della versione attuale e una directory .git con le informazioni necessarie al versionamento, e i repository bare, che espongono tutta la struttura del versionamento e non mostrano comodamente la versione corrente. Il primo tipo viene utilizzato per i repository locali, mentre il secondo è per i server, come in questo caso.

Il nostro primo repository sarà chiamato test. Per crearlo, dobbiamo prima di tutto creare una directory test.git nella home dell’utente git, per poi inizializzarci dentro un repository bare. Passiamo dunque all’utente git e creiamo il repository:

su git
cd
mkdir test.git
cd test.git
git --bare init

Questa operazione, ovviamente, andrà effettuata per ogni repository che vorremo creare.

Lato client

A questo punto dobbiamo installare Git anche sul nostro PC sul quale lavoreremo, e dobbiamo crearci il repository locale. L’installazione differisce un po’ a seconda del sistema operativo.

Linux

Qualunque distribuzione di Linux, per ovvi motivi, contiene una sua implementazione di Git. Basterà quindi installare il pacchetto corrispondente, molto semplicemente. Sulle Debian-derivate il nome del pacchetto è in genere git-core.

Windows

Git per Windows è disponibile su Git for Windows, distribuito col più classico dei setup. Basterà installarlo.

Mac OS X

Anche per Mac, viene distribuito un classico file dmg da installare.

Altri

Esistono implementazioni di Git anche per dispositivi mobili, su Android se ne trovano diverse. L’utilizzo però è differente, trattandosi di client grafici talvolta anche piuttosto limitati nelle funzionalità, e quindi non saranno trattati qui. Esistono, però, per chi volesse esplorarle.

Configurazione per tutti i sistemi

Qualunque sia la vostra scelta di sistema operativo, è necessario a questo punto aprire un terminale (o prompt dei comandi su Windows).

Nel terminale, daremo, una tantum, i comandi per configurare la nostra installazione di git in modo che firmi con nostri dati le modifiche che faremo noi:

git config --global user.name "Nome Cognome"
git config --global user.email indirizzo@ema.il

Se si hanno un editor di testo e un diff preferito, si possono impostare con i comandi:

git config --global core.editor emacs
git config --global merge.tool vimdiff

Fatto questo, navighiamo col terminale verso la directory in cui vogliamo mettere i file da tenere sotto controllo di versione, e generiamo il nostro repository locale legato a quello della nostra Raspberry Pi. Si assume che raspberrypi.local sia l’indirizzo mDNS della nostra Raspberry Pi:

git clone git@raspberrypi.local:/mnt/disco/git/test.git

Questo comando, come dice il suo stesso nome, fa un vero e proprio “clone” del repository presente sulla Raspberry Pi. Se quindi lo daremo riguardo un repository con già alcuni file all’interno, copieremo l’ultima versione di quel repository (e le informazioni per ottenere le precedenti).

I primi commit e push

Siamo finalmente pronti a caricare i nostri primi file sul sistema di versionamento. Dopo aver creato un file, che chiameremo test.txt, nella nostra directory, proviamo a dare il comando:

git status

Git ci avvertirà che è presente un nuovo file nella directory, e che non è ancora sotto controllo versione. Aggiungiamolo al meccanismo di controllo con il comando:

git add test.txt

Un nuovo git status ci dirà che ora il file è sotto controllo di versione, ma non ne è ancora stato fatto il commit. Un bel

git commit -m "Commento OBBLIGATORIO alla versione"

creerà una nuova versione, con il nuovo file dentro, del nostro progetto.

L’add andrà fatto ogni volta che vorremo preparare un file al successivo commit, ovvero se vogliamo metterlo in quella che viene chiamata area di staging. Quando il contenuto dell’area di staging è sufficiente ad essere considerato una nuova versione, è opportuno dare il commit.

Fatto il nostro commit, quando sarà il momento di voler caricare sulla Raspberry Pi le modifiche fatte sul nostro repository locale, sarà necessario dare il comando:

git push

e allo stesso modo, se si vogliono ottenere dalla Raspberry le modifiche fatte da altre persone, o su altre macchine, basterà dare il comando:

git pull

Per un utilizzo più avanzato, e per l’interessantissima gestione dei fork, sperando che quanto scritto finora possa bastare ad avvicinarsi a questo mondo, vi rimandiamo alla documentazione già linkata.

Credit immagine di copertina | Timothy Vogel

Leave a Reply

Lorenzo Breda Articolo scritto da

Studente di Informatica a Roma, si occupa di programmazione web sopratutto lato server, e di accessibilità del web. Utilizza e ama Debian GNU/Linux, e si interessa di fisica, fumetto, trekking e fotografia (gli ultimi due possibilmente abbinati). Collabora con Googlab da aprile 2012.

Contatta l'autore

Previous post:

Next post: