[Guida] Muovere i primi passi con il version control system Git [Parte 2]

Dopo una prima parte più teorica, in questo secondo articolo vi parlo di Git dando un taglio più pratico. Vi mostrerò come installare il vcs, come effettuare le configurazioni di base ed interagire con GitHub. Non mancherà qualche altro piccolo cenno teorico per chiarire alcuni concetti di base.

Git: installazione e configurazione

Prima di iniziare a utilizzare Git, dovete installare il sistema sul vostro computer o, se già presente, aggiornarlo. Su Debian, Ubuntu e derivate utilizzate:

sudo apt install git

Ora dovete sfruttare il tool git config per effettuare la configurazione di base. La prima cosa da fare è impostare il vostro nome utente e l’indirizzo e-mail. Questa operazione andrà effettuata una sola volta:

git config --global user.name "PaolinoPaperino"
git config --global user.email pp@tutanota.com

Potete ora scegliere l’editor di testo predefinito, ad esempio:

git config --global core.editor vim

La configurazione iniziale è completa. Per un riepilogo utilizzate la direttiva git config –list.

Git: creare un repository

Completata la fase di configurazione, è arrivato il momento di creare un nuovo progetto o importarne uno esistente. Per farlo le istruzioni sono le seguenti:

git init: trasforma la directory corrente in un nuovo repository Git;
git clone [url]: importa un repository già esistente da una posizione remota, ad esempio da GitHub.

Modified, Staged, Committed

Un file su cui lavoriamo, e che appartiene ad un repository gestito tramite Git, può trovarsi alternativamente in uno dei seguenti stati:

modified: file modificato in locale;
staged: file spostato nell’area di stage;
commited: file trasferito dall’area di stage al database locale, tramite il commit.

Ogni commit, quindi, crea una nuova child version di un contenuto che deriva dalla precedente parent version che avete modificato. Il contenuto viene memorizzato come una serie di versioni, chiamate snapshot, collegate dalla relazione genitore-figlio creata dalle operazioni di commit. Le informazioni che sono state modificate tra una versione padre ed una figlia dal commit sono chiamate changed set.

Ogni file nella vostra cartella di lavoro può essere nello stato tracciato o non tracciato. I file tracked sono quelli che erano contenuti nell’ultima istantanea. A loro volta, come vi ho spiegato poc’anzi, possono essere unmodified, modified o staged. I file non tracciati sono invece tutti quelli non inclusi nell’ultima istantanea e che quindi non si trovano nell’area di staging.

Trusted ed Untrusted

Il comando principale che serve a determinare quali file si trovano in quale stato è git status. Se eseguite questo comando direttamente dopo aver clonato per la prima volta un repository, quindi, dovreste vedere solo file tracked e unmodified. Questo ovviamente perché li avete appena estratti, come nel seguente output di esempio:

$ git status
On branch master				#vi trovate sul ramo master del repository
nothing to commit, working directory clean	#non ci sono file modificati da elencare

Provate ora ad aggiungere un nuovo file nella fase di stage del progetto. Dopo averlo creato utilizzare la direttiva:

git add prova.py

Lanciate, di nuovo, git status. Noterete un output come nel seguente screenshot, che evidenzia la presenza del file nella fase di staging.

Effettuate quindi il commit con git commit. A seguito di questa direttiva, Git crea una specie di snapshot di tutti file presenti in quel momento e salva un riferimento a questo istante in modo da poterlo riconoscere in futuro. Volendo essere precisi, in realtà Git crea, per ogni file del repository, un collegamento alla versione precedente già salvata.

Git log

Questa sequenza di operazioni viene sempre eseguita offline, cioè sul vostro computer locale. Dopo aver creato diversi commit o dopo aver clonato un repository con una cronologia dei commit esistente, potete controllare tutte le modifiche apportate al repository. Il comando che dovete utilizzare è git log.

Per impostazione predefinita, senza argomenti, git log elenca i commit effettuati in quel repository in ordine cronologico inverso, ovvero stampa prima i commit più recenti.

Siamo giunti alla conclusione di questa mini guida in due parti sul version control system Git. Questi articoli, ovviamente, volevano essere un’introduzione semplificata. Per avere una panoramica completa su tutte le funzionalità di Git, invece, vi rimando alla guida ufficiale.

Seguiteci sul nostro canale Telegram, sulla nostra pagina Facebook e su Google News. Nel campo qui sotto è possibile commentare e creare spunti di discussione inerenti le tematiche trattate sul blog.