Tutorial Git: primi passi con il sistema di controllo delle versioni

Lo sviluppo congiunto di progetti software non si verifica solo all’interno delle aziende: anche nel settore open source, a seconda delle di­men­sio­ni del progetto, da diverse centinaia a migliaia di volontari par­te­ci­pa­no alla ma­nu­ten­zio­ne, ot­ti­miz­za­zio­ne, sviluppo e modifica di un programma. Senza un adeguato sistema di re­gi­stra­zio­ne e controllo delle numerose modifiche da parte dei diversi svi­lup­pa­to­ri tali progetti dif­fi­cil­men­te po­treb­be­ro essere rea­liz­za­ti.

Una delle soluzioni più popolari per il controllo di versione è il tool Git non soggetto a licenza, semplice da imparare e com­ple­ta­men­te gratuito. In questo tutorial vi forniremo tutte le nozioni di base di Git ne­ces­sa­rie per iniziare con il programma di controllo delle versioni.

Git è un sistema di controllo versione svi­lup­pa­to nel 2005 dal creatore di Linux, Linus Thorvalds, e ri­la­scia­to sotto licenza GNU-GPLv2 gratuita. La par­ti­co­la­ri­tà dello strumento è che sebbene esista un re­po­si­to­ry centrale per ciascun progetto, tutti gli utenti coinvolti scaricano una copia locale di lavoro di questa directory sul proprio di­spo­si­ti­vo di lavoro. Ognuna di queste copie rap­pre­sen­ta un back-up completo del re­po­si­to­ry, per cui non è ne­ces­sa­ria una con­nes­sio­ne di rete continua per il processo di lavoro di base. Inoltre le copie fungono da back-up nel caso in cui la directory prin­ci­pa­le non dovesse fun­zio­na­re o è dan­neg­gia­ta. Le modifiche ef­fet­tua­te possono essere condivise in qualsiasi momento con tutti gli altri par­te­ci­pan­ti al progetto e, se opportuno, possono essere inserite nel re­po­si­to­ry.

Chi desidera ap­pren­de­re la gestione del software con Git dovrebbe in­nan­zi­tut­to fa­mi­lia­riz­za­re con il software e la relativa in­ter­fac­cia utente. Git è di­spo­ni­bi­le per Windows, Unix/Linux e macOS, tenendo conto che le diverse versioni si dif­fe­ren­zia­no leg­ger­men­te tra loro per quanto riguarda il fun­zio­na­men­to. Dopo l’in­stal­la­zio­ne standard potete con­trol­la­re lo strumento, in­di­pen­den­te­men­te dalla piat­ta­for­ma, sia con l’in­ter­fac­cia a riga di comando che con un’in­ter­fac­cia utente grafica.

Sull’homepage del progetto Git si trovano file di in­stal­la­zio­ne binari, istru­zio­ni per l’in­stal­la­zio­ne del gestore pacchetti (sistemi Unix) e edizioni portatili pronte all’uso per i singoli sistemi. È suf­fi­cien­te scaricare il pacchetto de­si­de­ra­to o uti­liz­za­re il pacchetto giusto della gestione pacchetti e seguire le istru­zio­ni della procedura guidata di in­stal­la­zio­ne. L’edizione portatile non prevede l’in­stal­la­zio­ne.

Una volta in­stal­la­to Git sul vostro sistema, potrete uti­liz­zar­lo per la gestione dei vostri progetti. Ma come con qualunque software è ne­ces­sa­rio in­nan­zi­tut­to conoscere le funzioni e i comandi ele­men­ta­ri per trarre il massimo beneficio dall’ap­pli­ca­zio­ne. Nell’ambito del nostro tutorial per prin­ci­pian­ti il­lu­stre­re­mo i passaggi chiave della con­fi­gu­ra­zio­ne di Git e del suo fun­zio­na­men­to tramite la riga di comando, in modo che in seguito possiate con­fi­gu­ra­re e con­trol­la­re fa­cil­men­te il vostro re­po­si­to­ry.

Il re­po­si­to­ry Git è la directory centrale di un progetto gestito e quindi anche il punto di contatto centrale per tutti i par­te­ci­pan­ti, at­tra­ver­so il quale viene re­go­la­men­ta­to il controllo completo della versione. Pertanto il vostro primo passo in Git è creare una directory prin­ci­pa­le o clonarla (sotto forma di una copia di lavoro) se aderite a un progetto il cui sviluppo congiunto è con­trol­la­to con l’ausilio di Git.

Se de­si­de­ra­te con­fi­gu­ra­re nuo­va­men­te il controllo di versione o avete sem­pli­ce­men­te in­stal­la­to lo strumento per imparare a lavorare con Git, conviene in­nan­zi­tut­to ri­co­sti­tui­re un re­po­si­to­ry. Per far questo uti­liz­za­te “cd” (change directory) per passare alla directory locale de­si­de­ra­ta sul vostro di­spo­si­ti­vo:

Per generare una directory .git eseguite ora il seguente comando:

Se il re­po­si­to­ry Git per il vostro progetto esiste già, vi occorre solo l’indirizzo web o di rete di questa directory per creare con il comando ”git clone“ una copia di lavoro sul vostro computer:

Tra i prin­ci­pa­li fon­da­men­ti di Git c’è una buona or­ga­niz­za­zio­ne della propria directory di lavoro. Tramite questa non solo proponete modifiche e in­no­va­zio­ni personali a un progetto, che vengono poi acquisite tramite commit (“at­ti­va­zio­ne”), ma ottenete anche in­for­ma­zio­ni sulle attività di altri utenti. Potete ve­ri­fi­ca­re l’ag­gior­na­men­to della vostra copia di lavoro mediante la seguente voce:

Per ag­giun­ge­re un nuovo file di controllo delle versioni o re­gi­stra­re un file mo­di­fi­ca­to per il prossimo commit applicate il comando “git add” a questo file (deve trovarsi nella directory di lavoro). Nel nostro tutorial Git ap­por­tia­mo come esempio un documento di testo chiamato “Test”:

Come descritto nel paragrafo pre­ce­den­te, tutte le modifiche che avete re­gi­stra­to per il controllo versione devono sempre essere con­fer­ma­te tramite commit affinché siano incluse nell’HEAD. L’HEAD è una sorta di indice che punta all’ultimo commit ef­fet­tua­to nel vostro attuale ambiente di lavoro Git (noto anche come “branch”). Il comando per questo passaggio è:

Come mostra lo screen­shot, dopo aver eseguito “git commit” ricevete un messaggio rie­pi­lo­ga­ti­vo sul commit: le parentesi quadre anteposte con­ten­go­no da un lato il nome del branch (ramo del progetto; qui “master” poiché la nostra directory di lavoro è anche la directory prin­ci­pa­le), in cui vengono tra­scrit­te le modifiche, dall’altro il checksum SHA-1 del commit (qui “c0fdc90“). Se­gui­ran­no il commento li­be­ra­men­te scelto (qui "test") e in­for­ma­zio­ni concrete sulle modifiche apportate.

Se avete apportato modifiche sotto forma di un commit, potete rivedere il contenuto in qualsiasi momento o revocarlo del tutto. Un caso tipico, in cui sono necessari degli ag­gior­na­men­ti, è ad esempio quello in cui il commit è stato generato troppo presto e sono stati di­men­ti­ca­ti alcuni file o modifiche im­por­tan­ti. In tal caso è ne­ces­sa­rio fornire a po­ste­rio­ri tramite “git add” i file nuovi o adattati e ripetere l’in­se­ri­men­to nel re­po­si­to­ry prin­ci­pa­le. Per far questo ag­giun­ge­te al comando standard l’opzione --amend:

Se de­si­de­ra­te invece revocare l’ultimo commit generato, potete farlo con il seguente comando Git:

Con questo comando viene revocato l’ultimo commit inserito nell’HEAD. I file in esso contenuti sono quindi reim­po­sta­ti allo stato “modifiche pia­ni­fi­ca­te per il prossimo commit”. Se invece i dati di lavoro devono essere com­ple­ta­men­te eliminati uti­liz­za­te il seguente comando al posto del pre­ce­den­te:

È im­por­tan­te imparare la gestione del progetto con Git, in par­ti­co­la­re per le fun­zio­na­li­tà ele­men­ta­ri di Ver­sio­ning. Un enorme punto a favore di questo sistema open source è il fatto che in qualsiasi momento è possibile vi­sua­liz­za­re le ultime modifiche apportate al re­po­si­to­ry. Il comando Git richiesto è:

Inoltre il comando log può essere mo­di­fi­ca­to uti­liz­zan­do diversi parametri. Nella seguente tabella sono elencate alcune opzioni utili:

Fin qui vi abbiamo mostrato in questo tutorial Git in che modo me­mo­riz­za­re le modifiche come commit nell’HEAD della directory locale. Ma affinché siano re­gi­stra­te anche nel re­po­si­to­ry prin­ci­pa­le è ne­ces­sa­rio immettere il seguente comando:

Con questo comando Git tra­sfe­ri­sce au­to­ma­ti­ca­men­te tutti i commit creati, finora presenti solo nella copia di lavoro, nella directory prin­ci­pa­le, chiamata anche “master”. Se nel codice indicato si so­sti­tui­sce questo nome con quello di un altro branch (ramo del progetto) i file verranno inviati di­ret­ta­men­te li.

Come molti altri sistemi di controllo versione anche Git dispone di una funzione di tagging, che consente di con­tras­se­gna­re come im­por­tan­ti dei punti se­le­zio­na­ti nella cro­no­lo­gia di un re­po­si­to­ry. Di solito questi tag sono uti­liz­za­ti per iden­ti­fi­ca­re le pub­bli­ca­zio­ni di un software come versione 1.0, 2.0 ecc., affinché possano essere re­cu­pe­ra­te fa­cil­men­te anche nei progetti di grandi di­men­sio­ni. Al riguardo Git supporta due tipi di tag:

• I tag annotati (“annotated“) sono me­mo­riz­za­ti come oggetti autonomi nel database inclusi il proprio checksum, il messaggio di tagging, la data, il nome e l’indirizzo di posta dell’autore del tag, nonché la firma GNU Privacy Guard opzionale (firma GPG).
• I tag non annotati (“light­weight“), proprio come i branch, fungono solo da ri­fe­ri­men­to a un commit. Questo tipo è utile se sono necessari solo tag tem­po­ra­nei o non si desidera salvare le in­for­ma­zio­ni ag­giun­ti­ve.

I tag annotati sono creati in Git uti­liz­zan­do il comando “git tag -a“ sul commit richiesto. Se si aggiunge anche il parametro “m” è possibile formulare il messaggio tagging de­si­de­ra­to, posto tra vir­go­let­te, di­ret­ta­men­te nell’in­ter­fac­cia a riga di comando. In questo tutorial Git abbiamo generato il commit “test”, che a tal fine associamo anche a un tag che include il messaggio “example tag”:

Per i tag non annotati procedete in modo simile, uti­liz­zan­do però solo il comando di base “git tag” sul commit de­si­de­ra­to e ri­nun­cian­do ad altri parametri. Riferito al nostro esempio il comando da eseguire è il seguente:

Non appena i tag saranno di­spo­ni­bi­li per il vostro re­po­si­to­ry, potrete vi­sua­liz­zar­li con il “git tag“ già noto e i parametri opzionali “-l“ o “--list“:

Per eliminare un tag dalla directory di lavoro locale applicate la stringa di comando “git tag -d“. Il nostro ri­fe­ri­men­to a “test” viene rimosso come segue:

Per inciso, anche i tag come i commit devono essere tra­sfe­ri­ti ma­nual­men­te nella directory prin­ci­pa­le. Per far questo sono necessari il nome del tag e il comando “git push origin“. Ma al posto del nome del tag potete anche inserire il parametro “--tags“, tramite il quale tutti i tag generati vengono re­gi­stra­ti nel re­po­si­to­ry:

I branch già citati in questo tutorial Git rap­pre­sen­ta­no in linea di principio solo singole versioni di lavoro del re­po­si­to­ry prin­ci­pa­le, clas­si­fi­ca­to a sua volta come branch, con il nome “master”. Con questi rami di lavoro Git fornisce la base perfetta per svi­lup­pa­re ca­rat­te­ri­sti­che e funzioni separate l’una dall’altra e uni­fi­car­le solo in un momento suc­ces­si­vo. Quest’ultima ope­ra­zio­ne viene de­no­mi­na­ta anche “merge“ (dall’inglese to merge “unire“).

Non è difficile creare un nuovo branch: vi occorre solo l’in­di­ca­zio­ne “git branch” alla quale ag­giun­ge­re l’etichetta de­si­de­ra­ta per il ramo. È possibile creare un branch di esempio chiamato “test_branch” nel modo seguente:

È quindi possibile passare a questo branch in qualsiasi momento con il comando "git checkout":

Se de­si­de­ra­te unificare i branch potete farlo con il comando “git merge“. Andate in­nan­zi­tut­to tramite “checkout” alla directory che deve re­gi­stra­re un altro ramo e lì eseguite il comando citato, compreso il nome del branch da re­gi­stra­re. Ad esempio la nostra versione di lavoro “test_branch” può essere unificata nel re­po­si­to­ry prin­ci­pa­le nel seguente modo:

Se avete unificato i rami di lavoro e quindi un de­ter­mi­na­to branch non vi serve più, potete sem­pli­ce­men­te eli­mi­nar­lo. Per far questo uti­liz­za­te la stringa di comando “git branch -d“ sul ramo della versione che non vi serve più. Con questo input potete eliminare Il nostro esempio del tutorial Git “test_branch“: