Come Usare Git – Parte I

Non hai la più pallida idea di cosa sia Git? Pensi che sia il nome della nuova macchina di Elon Musk? Ne hai bisogno per SO? Non c’è nulla di cui preoccuparsi: basta seguire questa guida introduttiva passo passo e presto prenderai dimestichezza con Git, tanto da vantarti con amici e parente di essere sviluppatore™.

Prima di approfondire, chiariamo un malinteso comune: Git non è la stessa cosa di GitHub. Git è un sistema di controllo della versione (cioè un pezzo di software) che ti aiuta a tenere traccia dei programmi e dei file del tuo computer e delle modifiche che vengono apportate ad essi nel tempo. Ti consente anche di collaborare con i tuoi colleghi su un programma, codice o file. GitHub e servizi simili (inclusi GitLab e BitBucket) sono siti Web che ospitano un programma server Git per contenere il tuo codice.

Che cosa è il controllo della versione?

Il controllo della versione è la pratica di tracciare e gestire le modifiche al codice software. I sistemi di controllo della versione sono strumenti software che aiutano i team di software a gestire le modifiche al codice sorgente nel tempo. Con l’accelerazione degli ambienti di sviluppo, i sistemi di controllo delle versioni aiutano i team del software a lavorare più velocemente e in modo più intelligente.

Supponiamo per esempio che il tuo compagno di lavoro stia lavorando ad una certa funzione su un progetto, mentre tu sei impegnato a riscrivere un’altra funzione. A lavoro concluso, se volessimo riunire le modifiche del tuo compagno e del tuo lavoro, normalmente dovremo confrontare i due file ed effettuare manualmente copia/incolla/sposta. Oltre alla perdita di tempo e di efficienza, il processo non sempre è dei migliori dato che gli esseri umani spesso e volentieri commettono errori. Il controllo della versione al contrario permette la gestione semplice e immediata di diverse versioni del codice sorgente, senza preoccuparsi di conflitti e/o sostituzione.

Git

Git (nello slang britannico significa “idiota”) è un software utilizzato per il controllo della versione, inizialmente sviluppato nel 2005 da Linus Torvalds. Dopo aver provato sistemi propretari per il controllo della versione, Linus cercò di sviluppare da zero un nuovo sistema open-source che garantisse alte prestazioni per facilitare il suo lavoro nel patching (“applicare una patch”) del kernel Linux.

La principale differenza tra Git e qualsiasi altro VCS (Subversion e amici inclusi) è il modo in cui Git pensa ai suoi dati. Concettualmente, la maggior parte degli altri sistemi memorizza le informazioni come un elenco di modifiche basate su file. Questi altri sistemi (CVS, Subversion, Perforce, Bazaar e così via) considerano le informazioni che archiviano come un insieme di file e le modifiche apportate a ciascun file nel tempo (questo è comunemente descritto come controllo della versione basato su delta files).

Git non memorizza i suoi dati in questo modo. Al contrario, Git pensa ai suoi dati più come una serie di istantanee di un filesystem in miniatura. Ogni volta che commetti o salvi lo stato del tuo progetto, Git fondamentalmente fa un’immagine di come appaiono tutti i tuoi file in quel momento e memorizza un riferimento a quell’istantanea (in gergo tecnico, commit). Per essere efficiente, se i file non sono cambiati, Git non memorizza di nuovo il file, ma solo un collegamento al file identico precedente che ha già memorizzato.

Pensiamo al commit come ad una foto del nostro progetto. Questo oggetto contiene anche il nome e l’email dell’autore, il messaggio che hai digitato (spesso è la descrizione del commit) e i puntatori al commit o ai commit che sono venuti direttamente prima di questo commit (il suo genitore o i suoi genitori). Un ramo in Git è semplicemente un puntatore leggero a uno di questi commit. Il nome del ramo predefinito in Git è master (o per essere più politicamente corretti main). Quando inizi a fare commit, ti viene assegnato un ramo principale che punta all’ultimo commit che hai fatto. Ogni volta che fai un commit sul branch, si sposta in avanti automaticamente. Affronteremo la parte del branching in modo più dettagliato nella seconda parte.

Nei prossimi paragrafi, introdurremo i primi comandi per prendere dimestichezza con Git e come fare il primo commit direttamente sul branch main.

Clonare una nuova repository

Per clonare una nuova repository è sufficiente utilizzare:

git clone URL_REPO

dove URL_REPO è il link alla repository. Nel nostro esempio, la repository si chiamerà first-repo.

Git Status

Il comando git status è molto utile per verificare lo status della nostra repository. Restituisce all’utente tutta una serie di informazioni riguardo file non tracciati, quali file sono pronti per il commit e quali sono stati modificati. È molto utile le prime volte per capire effettivamente cosa includiamo all’interno di una commit e cosa no.

Aggiungere file per la modifica

Una volta che abbiamo clonato la nostra repository vuota e scritto un po’ di codice, dobbiamo notificare a Git la presenza di nuovi file che vogliamo tracciare per la prossima commit. Se ad esempio abbiamo la cartella src con dentro il file main.c, possiamo direttamente aggiungere la cartella src (e tutti i file dentro questa cartella) attraverso il comando:

git add src/

L’output di Git restituisce tutti i file aggiunti al tracking e può essere eseguito più volte prima di un commit. Aggiunge solo il contenuto dei file specificati al momento dell’esecuzione del comando add. (Quindi qualsiasi altra modifica fatta dopo il comando add non è tracciata nella commit). Tutti i file tracciati vanno nella cosidetta area di staging, pronti per essere committati all’interno della repository.

In git non è possibile tenere traccia di cartelle vuote. Uno dei tanti workaround è di creare un file vuoto all’interno della cartella utilizzando il comando touch .gitkeep.

Se i file sono già stati “tracciati” precedentemente (ovvero se Git ha già qualche informazione sulla struttura della vostra repo) e vogliamo aggiornare il contenuto del file, basta semplicemente chiamare il comando git add -u: Git andrà a valutare ogni file di cui ha già presente il percorso. Se chiamassimo invece git add nome_cartella per ogni modifica, git andrebbe ad effettuare una index piuttosto pesante in termini di tempo e risorse sulla cartella nome_cartella.

Effettuare una commit

Ora che l’area di staging è configurata nel modo desiderato, puoi confermare le modifiche. Ricorda che tutto ciò che non è ancora in stage (qualsiasi file che hai creato o modificato su cui non hai eseguito git add quando li hai modificati) non andrà in questo commit, ma rimarranno come file modificati sul disco.

Per eseguire la commit è sufficiente eseguire questo comando:

git commit -m "Messaggio esauriente su cosa ho committato"

dove la flag -m (--message) indica il messaggio che verrà inserito nella commit. Spesso è buona norma includere nel messaggio della commit racchiude una breve descrizione delle modifiche o aggiunte dei diversi file.

Caricare i file

Per caricare i file in remoto, eseguiamo il seguente comando dove nome_branch è il nome del ramo su cui vogliamo caricare il commit.

git push origin nome_branch

Spesso e volentieri questo tipo di comando richiede l’autenticazione (Basic o via token).

Traduzioni