IMPORTANTE - Questa pagina è scaduta 2779 giorni fa (il 10 Febbraio 2014). Puoi trovare una versione aggiornata dell'articolo GIT, una guida al controllo di versione per i tuoi repository software sul nuovo sito web Netdesign.

Sei comunque libero di consultare questa pagina, abbiamo deciso di lasciarla online per trasparenza e per rispetto nei confronti del nostro passato e del nostro lavoro. Questo sito web è stato pubblicato ad Ottobre 2011 ed è scaduto a Febbraio 2014.

ATTENZIONE! Le informazioni riportate in questa pagina non sono più valide o aggiornate e non rappresentano in alcun modo il sito web ufficiale di Netdesign a partire dal 10 Febbraio 2014.

NOTA: Questa pagina potrebbe contenere link rotti e quindi non più funzionanti.

Developers Network

Risorse ed articoli su Javascript, PHP, Python e CSS per Web designer e sviluppatori Web. Consigli utili per un corretto sviluppo di pagine ed applicazioni web.

GIT, una guida al controllo di versione per i tuoi repository software

Git è un tool per il controllo di versione di progetti di sviluppo software. Permette di tenere traccia dei cambiamenti di un repository aiutando lo sviluppatore nel produrre software mantenibile.

Articolo pubblicato il 02/11/2012

Cos'è GIT

GIT è un DVCS free ed open source per il controllo di versione distribuito di progetti software di qualunque natura. Il primo lead developer di GIT fu Linus Torvalds, che, durante lo sviluppo del Kernel Linux, si era imbattuto nell'esigenza di utilizzare uno strumento che potesse gestire in maniera efficiente ed elegante progetti software estesi, sia dal punto di vista della quantità e del peso in Kilobyte dei sorgenti ma anche dal punto di vista del numero di sviluppatori coinvolti.

Il Kernel Linux fu uno dei primi fruitori di GIT e fu addirittura uno dei motivi per il quale lo stesso Torvalds decise di avviarne lo sviluppo.

Il Concetto di repository

Il repository è, nell'ambito del controllo di versione del software e più in generale dell'SCM, un deposito di file sorgenti controllati da un software dedicato, il quale tiene traccia della cronologia delle modifiche apportate ai singoli files. In parole più semplici è una directory contenente i sorgenti di un programma ed inizializzata, per l'appunto, come repository GIT (ma anche repository Mercurial o Bazaar, altri due tool simili a GIT).
In un qualsiasi repository, successivamente all'inizializzazione, viene creata una directory nascosta - chiamata .git o diversamente in base all'SCM scelto - che conterrà tutte le informazioni ed i metadati relativi all'indice dei file, ai commit e alle branches; tale directory nascosta è la principale e unica responsabile per la corretta gestione e mentenimento del repository tanto che, nei dannati casi di corruzione del filesystem, può essere impossibile ricomporne la cronologia (tranne nel caso in cui si sia provvidenzialmente provveduto ad un backup o ad una copia remota usando ad esempio rsync).

Usare GIT in un repository locale

Lo scenario più semplicistico nel quale può essere implementato GIT è l'utilizzo in locale, all'interno di un ambiente che coinvolga un singolo sviluppatore che lavori ai propri progetti software su un singolo computer. Data la natura distribuita di GIT è però possibile - e spesso consigliabile - integrare nella propria infrastruttura uno o più server GIT remoti, fondamentali per aggiungere ridondanza ai propri repository ed utilissimi per la condivisione dei sorgenti con altri collaboratori o colleghi. Se il tuo ambiente di lavoro risponde ai requisiti citati, l'utilizzo di GIT in locale è il punto di partenza per uno sviluppo in solitaria, offrendo comunque un approccio ed una forma mentis tipica dell'ingegneria del software, che prevede un completo controllo del ciclo di vita di un software.

GIT, guida ai comandi basilari

Prima di utilizzare GIT è di fondamentale importanza capirne il funzionamento e le logiche interne tenendo in considerazione le seguenti linee guida:

  • GIT non è un demone e tiene traccia soltanto dei file che vengono esplicitamente aggiunti all'indice.
  • Qualsiasi comando GIT va eseguito all'interno della root del repository o comunque nell'albero delle directory sottostanti.
  • Alcuni comandi GIT, come git submodules, devono obbligatoriamente essere eseguiti nella root del repo.
  • È consigliabile tenere sempre sotto controllo lo stato dell'indice e delle modifiche, evitando di aggiungere al repo i file inutili - come i file temporanei - o anche i file binari pesanti (GIT non è eccezionale nella gestione dei file di grosse dimensioni e non è ottimizzato per gestire le differenze per tali file).
  • Su GNU/Linux esistono parecchie interfacce grafiche che interagiscono col client a riga di comando. Alcune sono ben fatte ma, può sembrare assurdo, abbassano il livello di affidabilità del tuo repository durante il loro utilizzo: ci è più volte capitato che un Kernel Panic o un riavvio dell'interfaccia grafica (i soliti misteri di Ubuntu) durante una sessione con git-cola, abbiano prodotto una corruzione dell'indice di GIT con successive ed eccessive sudorazioni e palpitazioni! L'utilizzo del client a riga di comando garantisce una più alta affidabilità in quanto più in sintonia con il paradigma ACID.

Inizializzare un repository

La prima operazione da eseguire per iniziare ad utilizzare GIT per i propri progetti di sviluppo software è l'inizializzazione di un repository. Per inizializzare un repository software è sufficiente dirigersi all'interno della directory contenente i sorgenti e digitare:

git init

Tale comando, a conferma della creazione del repo, restituirà in output:

Initialized empty Git repository in /home/user/path/to/repo/.git/

dove .git/ è la directory che conterrà tutti i metadati del repository.

Aggiungere file e sorgenti all'indice del repo

Una volta inizializzato il repository è quindi d'obbligo aggiungere al repo i file sorgenti del proprio progetto così da permettere a GIT di tracciarne lo storico delle modifiche. Ipotizziamo di aver inizializzato un repository in una directory che conteneva già alcuni file sorgenti, ad esempio la struttura base di un semplicissimo sito web. La nostra directory di riferimento avrà quindi la seguente struttura:

. ├── index.html ├── libs │   └── main.js ├── README.mkd └── stk ├── logo.png └── style.css 2 directories, 5 files

Per rendersi conto dello stato del repository è quindi necessario eseguire il comando:

git status

che restituirà in output la lista dei file o delle directory contenenti file non tracciati (untracked):

# On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # README.mkd # index.html # libs/ # stk/ nothing added to commit but untracked files present (use "git add" to track)

Come già suggerisce l'output del comando git status, è adesso necessario eseguire il comando:

git add . // Il '.' è un wildcard e matcha tutti i file nella directory

per aggiungere all'elenco delle modifiche tutti i file presenti nella directory (per il successivo commit).
Eseguendo nuovamente il comando git status, avremo la visibilità dei file selezionati per il successivo commit. GIT sottolinea quindi che ci sono modifiche per le quali è necessario un commit:

# On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: README.mkd # new file: index.html # new file: libs/main.js # new file: stk/logo.png # new file: stk/style.css #

Eseguire un commit dopo le modifiche

Ora che il nostro repository è stato inizializzato ed i file sorgenti sono stati aggiunti all'indice, è importante identificare tale operazione con un commit con l'obiettivo di registrare permanentemente le modifiche (in questo caso l'aggiunta dei file) corredandole con un commento testuale:

git commit -m "Initial Commit" // Il flag -m indica il messaggio da assegnare al commit

Adesso è possibile continuare a lavorare sulla propria codebase apportando tutte le modifiche necessarie con la certezza di potersi sempre spostare all'interno dell'intera lista dei commit del repository. Ipotizziamo dunque di aggiungere un altro file, un'immagine chiamata banner.png nella directory ./stk/:

git add ./stk/banner.png git commit -m "Add homepage banner"

Con le due precedenti righe di codice abbiamo aggiunto il file banner.png alle modifiche da tracciare e le abbiamo successivamente aggiunte all'indice con il commento "Add homepage banner".

Visualizzare il log delle modifiche

A questo punto è già possibile visualizzare lo storico delle modifiche apportare al repository usando il comando:

git log

che in output ci restituirà:

commit 06abe2c90c358745309e28901f5c39b9d7fa2ba4 Author: author <author@laptop.(none)> Date: Sat Nov 3 23:49:55 2012 +0100 Add homepage banner commit a4483f1dc5ccd98c92677728f60cae5e89f23ef7 Author: author <author@laptop.(none)> Date: Sat Nov 3 23:49:43 2012 +0100 Inizial Commit

Visualizzare un repository GIT via web

Capita spesso, soprattutto nei progetti complessi, di aver bisogno di visualizzare lo storico delle modifiche o anche la lista dei file del proprio repository attraverso un'interfaccia web. GIT offre di default uno strumento utilissimo che, appoggiandosi a lighttpd o ad un qualsiasi altro webserver, permette di navigare nel proprio repository GIT tramite interfaccia web. L'eseguibile in questione si chiama git-instaweb, e, per avviarlo bisogna eseguire il seguente comando:

git instaweb --httpd /usr/sbin/apache2 // Il PATH /usr/sbin/apache2 è valido su Ubuntu, // Su CentOS l'eseguibile di Apache è /usr/sbin/httpd

Il flag --httpd è necessario per specificare l'eseguibile del webserver da utilizzare dato che nella sua configurazione base, git-instaweb ricerca, all'interno del sistema, l'eseguibile di lighttpd.
Subito dopo l'avvio del comando verrà avviato il browser di default con l'indirizzo e la porta preimpostati da git-instaweb.
Il processo di instaweb resterà sempre in vita, è quindi necessario bloccarlo manualmente col comando:

git instaweb --stop

0 Risposte a GIT, una guida al controllo di versione per i tuoi repository software


Lascia un Commento

La tua email non verrà pubblicata ma sarà utile per notificarti le risposte al tuo commento. I commenti considerati spam non verranno pubblicati. Puoi utilizzare i seguenti tag html nel commento: <p>,<b>,<strong>,<code> e <em>.

Il tuo Nome:



Il tuo indirizzo email:



Il tuo Commento:

Invia Commento

Twitter Stream

Contatta Netdesign

Hai bisogno di consulenza sul mondo dello sviluppo web e dell'ottimizzazione della tua infrastruttura informatica? Contattaci subito, ti aiuteremo a trovare le migliori soluzioni alle tue esigenze di Information Techonology.

Contattaci




Questa pagina è scaduta 2779 giorni fa (il 10 Febbraio 2014). Puoi trovare una versione aggiornata di questo/i articolo/i sul nuovo sito web Netdesign alla sezione Guide

Sei comunque libero di consultare questa pagina, abbiamo deciso di lasciarla online per trasparenza e per rispetto nei confronti del nostro passato e del nostro lavoro. Questo sito web è stato pubblicato ad Ottobre 2011 ed è scaduto a Febbraio 2014.

ATTENZIONE! Le informazioni riportate in questa pagina non sono più valide o aggiornate e non rappresentano in alcun modo il sito web ufficiale di Netdesign a partire dal 10 Febbraio 2014.

NOTA: Questa pagina potrebbe contenere link rotti e quindi non più funzionanti.