Articolo introduttivo -> Introduzione a GitLab

La pagina iniziale di GitLab si presenta come nell’immagine sottostante, con una toolbar nella parte alta, accompagnata sulla sinistra dal riquadro delle attività (riferito al repository attuale) e con accesso diretto alle brach di ogni file. Cliccando su Commits è possibile vedere la relativa cronologia, oltre che lo stato delle ramificazioni tramite la sezione Branches. La funzione commit consente di individuare gli utenti e le relative attività svolte sui file del repository (aggiunta, modifica, cancellazione).

GitLab: creare un repository

Per poter utilizzare GitLab occorre registrarsi sul sito gitlab.com e creare un proprio account. Una volta in attivato ci si troverà nella schermata iniziale dei progetti, cui si accede facendo clic sulla voce Projects della toolbar. Nella finestra che appare si trovano quattro opzioni sotto forma di icone e il modo migliore per partire con un progetto è creare prima un gruppo (in modo da definire il macro-contenitore di repos, utenti e permessi), per poi cliccare sulla voce Create a Project. In questa fase si può scegliere tra la creazione di un progetto da zero, l’utilizzo di un template, oppure l’import di un lavoro già realizzato altrove.

Nella sezione Visibility level possiamo definire il grado di protezione del progetto tra privato, interno (chiunque sia loggato su gitlab.com) o completamente pubblico. Quest’ultimo è il caso di progetti open cui possono contribuire tutti, mentre Internal è una soluzione ideale se GitLab è installato su una piattaforma on-premises.

Nella finestra di gestione vera e propria del progetto vuoto si può effettivamente iniziare a lavorare, aiutati dal riquadro dove sono elencati, divisi per categoria, tutti i comandi disponibili. I comandi Global Setup servono a configurare l’ambiente nel complesso (in pratica sono quelli riguardanti l'utente che crea il repository) mentre quelli in Create a New Repository riguardano la creazione di repository da zero; Existing folder contiene i comandi per la gestione da cartelle esistenti ecc. 

È anche possibile impostare GitLab e costruire o gestire i repository da linea di comando, sfruttando i corretti comandi e relativa sintassi. La prima cosa da fare è creare una directory (mkdir o equivalente in base alla shell utilizzata) per il repository, con il relativo file README introduttivo.

A questo punto bisogna inizializzare il progetto basato su Git tramite il comando git init, a cui il sistema risponderà confermando che è stato inizializzato il repository. È possibile automatizzare il processo di creazione grazie ad AutoDevOps: questo tool, sulla base della configurazione CI/CD (Cointuous Integration e Continuous Delivery) predefinita, costruirà, testerà e distribuirà l’applicazione in maniera automatica. In questo caso sarà possibile intervenire con le modifiche del caso sull’applicazione creata, per personalizzarla.

Impartendo il comando git status possiamo quindi vedere la situazione attuale del progetto, che nella fase attuale risponderà come "nulla sul branch master" dato che non viene trovato alcun file. Aggiungiamo quindi il file README con il comando git add README.md (per MacOS, ma se usate Windows il nome completo di estensione sarà README.txt).

Se ora impartite il comando git status apparirà, dopo no commits yet, il nome del file README.

Possiamo dunque introdurre la prima versione del codice, ossia creare il primo commit da riga di comando: il comando sarà git commit -m "testo messaggio”. Ogni commit deve avere associato un messaggio per l'identificazione. Nella figura seguente il messaggio è "il nostro primo commit".

Premendo il tasto Invio si esegue il comando e il commit viene creato, allorché tornando sulla finestra di GitLab possiamo vedere che per il momento nulla appare, in quanto in riga di comando abbiamo lavorato in locale sul nostro PC ma ancora nulla è stato trasferito di GitLab. Allo scopo, sempre dalla finestra CLI si procede all’upload con il comando git remote add origin, seguito dall'URL per trasferirlo sul server remoto GitLab. Tale indirizzo – che in pratica è il nome del repository che abbiamo creato in locale – si può reperire dalla casella HTTPS situata nella finestra di GitLab su Overview>Details. A questo punto la schermata di GitLab apparirà aggiornata.

Il push di tutto l’ambiente locale verso il server si effettua grazie al comando git push -u origin master 

Poco dopo, dalla finestra di lavoro di GitLab, sempre in Overview>Details, vedrete aggiornarsi la situazione del repository, con indicata la cronologia dei commit.

Accedendo alla sezione Repository > Branches si può crare un nuovo branch tramite il pulsante New branch che troviamo alla destra dello schermo. Una volta dato un nome al nuovo ramo, questo apparirà come ramificazione del master.

Gli Issues di GitLab

Una funzione molto interessante di GitLab sono gli Issues (compiti), che permette di gestire il lavoro di gruppo, assegnando e ricordando ai vari membri del team le attività e compiti assegnati.

Per utilizzare questo strumento si accede come solito nella sezione sinistra della schermata di GitLab e cliccando sulla apposita voce Issues per accedere alla relativa finestra di lavoro: l'esercitazione che proponiamo consiste nel creare una nota per un utente che ricordi di eseguire la modifica in un branch e questa modifica verrà introdotta nel branch staging.

Nella finestra Issues facciamo clic su New Issue assegnando un titolo che, nello specifico, definire la modifica stessa: il cambiamento verrà apportato nel file README.

Nella parte bassa della finestra possiamo decidere chi sarà il destinatario di questo Issue, ovvero se renderlo riservato (confidential). Cliccando sul pulsante Submit Issue in fondo alla pagina verrà inviato l'Issue.

Anche in questo caso, la sincronia tra GitLab e ambiente locale va effettuata da linea di comando, per poter visualizzare la stessa situazione in entrambi i contesti. Per farlo occorre impartire il comando git pull, che dice a GitLab di tirarsi dietro, ovvero caricare, sul computer locale le ultime modifiche apportate via Web.

L'immagine qui di seguito illustra il risultato del pull, che sostanzialmente comunica che non c'è alcun nuovo file, ma che è stato attivato un nuovo branch. Per eseguire l'Issue bisogna spostarsi sul branch staging, tramite il comando git checkout staging (git checkout indica a GitLab di passare da un branch all'altro, ossia sul branch di cui viene indicato il nome).

A questo punto, sempre dalla finestra della riga di comando, bisogna aggiornare e salvare il file README.

Tornati sulla CLI, ripetiamo le operazioni già viste per aggiungere il file modificato, ovvero impartiamo il comando git add README.txt (git add README.md per MacOS). A questo punto salviamo il commit (vedere immagine seguente) con il comando git commit -m "messaggio da inserire".

Con il comando git push -u staging possiamo visualizzare il risultato del push e aggiornare il repository presso GitLab, che sarà visibile e aggiornato dopo qualche istante. A questo punto si può considerare chiuso l'Issue e se necessario si possono aggiungere messaggi per altri componenti del team.

Altre funzioni di GitLab

Passiamo adesso a un'altra funzione di GitLab che è Container Registry (d’ora in poi CR): essa viene installata automaticamente nelle versioni recenti (dal 2017) di GitLab sia in remoto sia in locale (con una configurazione specifica). La finestra di Container Registry è mostrata nell’immagine seguente.

CR è una funzione che serve a gestire le immagini di Docker e l’interazione con esse e permette ad ogni progetto GitLab di avere uno spazio in Docker.

Passiamo oltre e vediamo un’altra funzione, che è la CI/CD (Continuous Integration, Continuous Delivery) già nominata in precedenza, contenente alcuni strumenti specifici per adempiere queste funzionalità e accessibili dal menu contestuale che si apre quando si clicca su CI/CD. Come vedete nel menu laterale, c’è poi la possibilità di creare delle Wiki per il proprio team o condivise con tutti gli utenti GitLab, degli Snippet ovvero? ecc. Ciascuna funzione è accessibile dalla specifica voce di menu.

Merge e visualizzazione delle modifiche in GitLab

Funzione fondamentale per il lavoro in team è il merge, ovvero la possibilità di gestire una “fusione” delle modifiche effettuate da vari utenti all’interno di un branch. Visivamente, tali modifiche saranno evidenziate con colori differenti e distinte per autore facilitando la comprensione e la consultazione.

Per avviare il merge, una volta aperta la finestra del branch è sufficiente fare clic sul pulsante Merge request. La schermata relativa permette di vedere le differenze tra il progetto “committato” e il progetto successivamente modificato e vengono visualizzati tutti i dati da quando abbiamo fatto il primo commit, senza il rischio di perdere nemmeno una riga di codice. Accanto alle modifiche può apparire un punto esclamativo: si tratta del segnale di git Git per i cambiamenti rilevati.

Per ogni progetto è disponibile una struttura ad “albero” che consente di ripercorrere a ritroso le modifiche attraverso i commit, fino all’origine del progetto stesso, oltre a poter cancellare i branch aperti nel tempo.