I siti web Netdesign utilizzano cookies. Maggiori informazioni alla pagina Informativa Cookies. Continuando la navigazione accetti il loro utilizzo. Se non desideri i Cookie vai alla pagina Opt out Cookies

Buon Mercoledì da Netdesign -Vieni a trovarci su Facebook o Twitter, scrivici a info@netd.it o chiamaci ai numeri 095 293 18 11 / 338 94 23 302

GIT - Guida al controllo di versione per i tuoi repository software

ATTENZIONE! Il contenuto di questo articolo necessita di revisione perché redatto più di un anno fa. I comandi e la sintassi utilizzata potrebbero non funzionare in seguito a cambiamenti o aggiornamenti del software. Scrivici a Questo indirizzo email è protetto dagli spambots. E' necessario abilitare JavaScript per vederlo. se hai bisogno di assistenza.

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 come Apache, 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 il PATH dell'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

Branching e Merging con GIT

Come tutti gli strumenti SCM, GIT possiede un potente strumento per la gestione delle branches ed il loro successivo merging.

Cos'è il branching

Immagina di avere la possibilità di effettuare degli snapshots istantanei e coerenti in un dato momento di sviluppo del tuo codice sorgente. Immagina poi di dover risolvere un bug nel tuo codice sorgente senza voler apportare modifiche alla versione stabile del tuo sorgente. È in questi casi che potrai godere dei vantaggi offerti degli strumenti di branching di GIT (o di altri SCM).

Il branching, in italiano diramazione o ramificazione, è quindi la possibilità di "bloccare" la tua base di sorgenti in un dato punto, potendo continuare lo sviluppo su una nuova branch "ramificata" da quella originale. In altre parole potrai scrivere il tuo codice in un ambiente parallelo che solo successivamente, quando le tue modifiche saranno stabili, potrai fondere nuovamente con la branch master.

Per un maggiore approfondimento delle funzionalità di GIT rimandiamo alla guida ufficiale in italiano ed in inglese.

Potenziali criticità del branching

GIT è uno strumento molto potente ma non divino! Questo significa che per quanto possa supportare lo sviluppatore nelle attività di menutenzione del codice sorgente, è buona norma seguire un approccio il più lineare possibile ed evitare di sviluppare contemporaneamente su due branch parallele modificando gli stessi file sortgente: in questo modo, quando vorrai fare un merge potresti incorrere in conflitti tra i codici sorgente che dovrai - a volte con molti sforzi - risolvere manualmente.

Ecco in basso un esempio di merge tra due branch in cui si verificano conflitti nei sorgenti "topbar.html" e "navbar.html".

fabiobuda@netdesign:~/project/devel$ git merge testing
Auto-merging project/settings/local.py
Auto-merging project/apps/mobile/models.py
CONFLICT (content): Merge conflict in project/apps/frontend/topbar.html
CONFLICT (content): Merge conflict in project/apps/frontend/navbar.html
Auto-merging project/apps/mobile/admin.py
Merge automatico fallito; risolvi i conflitti ed eseguire il commit
del risultato.
Hai trovato utile questo articolo?
Lasciaci un tuo sincero feedback

Pubblicati di recente

Articoli e documenti pubblicati di recente su questo sito web

  1. Quale piattaforma Ecommerce scegliere? Cerchiamo di chiarirvi le idee con parole semplici
    online dal 07.06.2019
    ultima modifica il 07.06.2019


  2. Netdesign al Liceo Einaudi di Siracusa
    online dal 08.03.2019
    ultima modifica il 08.03.2019


  3. La SEO è cambiata: #Sapevatelo!
    online dal 09.02.2019
    ultima modifica il 09.02.2019


  4. Posso ottenere un certificato SSL per il mio sito web?
    online dal 05.02.2019
    ultima modifica il 05.02.2019


  5. Come ottenere l'accesso ai dati di analytics del mio sito web?
    online dal 05.02.2019
    ultima modifica il 05.02.2019


  6. Cos'è e cosa significa SEO?
    online dal 05.02.2019
    ultima modifica il 05.02.2019


Ulteriori articoli recenti