The Linux Nerd

GNU/Linux: primi passi con Git, spiegato semplice

Git è uno dei sistemi di controllo delle versioni più famosi al mondo, quello che si usa per gestire anche il kernel di Linux. È uno strumento enorme, e io gli dedicherò diverse puntate. Questa è la prima: le basi, con calma, perché a me piace partire dai fondamentali per darvi una conoscenza completa e profonda, non una raccolta di comandi da ricopiare.

Cos’È git

Tecnicamente Git è un sistema di controllo delle versioni: un software che tiene traccia delle varie versioni di uno o più file nel tempo. Immaginatelo come una macchina del tempo, o una cronologia delle modifiche. L’unica cosa da ricordare è che siete voi a decidere quali sono i punti nel tempo da salvare: le modifiche vengono raggruppate come volete voi, e quei punti sono quelli a cui potrete tornare, o con cui potrete fare confronti.

Il punto di forza di Git è la semplicità architetturale: è un software con tantissime opzioni e una complessità enorme, ma capire com’è strutturato e quali sono le sue funzioni di base è molto facile.

Il repository

Un repository è un insieme di file e cartelle tenuti sotto il controllo di versione di Git. Pensatelo come un progetto, o una cartella dentro la quale Git tiene traccia delle variazioni nel tempo. Sul vostro computer potete avere quanti repository volete, uno per cartella. Si possono anche annidare, ma è un argomento avanzato e ci arriveremo.

Cominciamo da una cartella vuota. Tutti i comandi di Git cominciano con git, e quello per creare un repository è init:

mkdir esempio
cd esempio
git init

Git ci dice che ha inizializzato un repository vuoto nella cartella. È stata creata una sottocartella nascosta, .git, che contiene tutte le informazioni di lavoro del repository. I file da monitorare stanno nella cartella esempio, allo stesso livello di .git, e possono essere file, cartelle, sottocartelle, quello che volete.

Configurazione

La prima cosa da fare è configurare il repository con il comando git config. Le opzioni sono tantissime, ma per cominciare ne servono due sole: il nome e l’email, che Git assegnerà a ogni commit, cioè a ogni salvataggio di snapshot. Le virgolette servono perché il nome contiene spazi:

git config user.name "Il Tuo Nome"
git config user.email "tuo@indirizzo.it"

Così il repository sa che firma mettere sugli snapshot.

Il primo file E git status

Per capire come ragiona Git creiamo un primo file, frutta.txt, e scriviamoci dentro qualche riga di frutta (una per riga):

nano frutta.txt

Ora incontriamo il comando che dovete imparare a usare bene e, soprattutto, di cui dovete saper interpretare l’output:

git status

Ci dà alcune informazioni fondamentali:

  • il nome del branch su cui ci troviamo. I branch sono i filoni di sviluppo, le diverse linee temporali del repository: si possono separare e riunire, ma in ogni istante siamo attivi su uno e un solo branch;
  • la scritta “No commits yet” (commit iniziale), che dice che siamo all’inizio della cronologia;
  • la sezione “Untracked files”: file presenti nella cartella ma di cui Git non traccia le modifiche. Sono invisibili per la cronologia, e dobbiamo decidere cosa farne: tracciarli oppure ignorarli (per ignorarli esiste il file .gitignore, ma ci arriviamo).

Aggiungere I file E la zona di staging

Vogliamo tracciare frutta.txt, quindi lo aggiungiamo:

git add frutta.txt

Ora git status ci segnala “Changes to be committed”. Che cos’è un commit? È un concetto fondamentale: uno snapshot, un punto sulla linea temporale, un’immagine del repository cristallizzata nel tempo e identificata da una chiave univoca. Ogni commit è un istante bloccato e richiamabile tramite quella chiave.

Ma attenzione: quando facciamo git add, le modifiche non diventano subito un commit. Vengono messe in un’area di attesa, la famosa (o famigerata) zona di staging. È una caratteristica importantissima: capire a cosa serve e quando usarla distingue l’utente esperto. Per ora immaginatela come una sala d’aspetto, prima che le modifiche vengano trascritte nel repository.

Vediamo cosa succede se modifico ancora frutta.txt mentre la versione precedente si trova nella zona di staging:

nano frutta.txt
git status

Adesso ci sono due cose: le modifiche in staging (“Changes to be committed”) e le modifiche successive non in staging (“Changes not staged for commit”), che non verranno scritte nel repository quando faremo il commit. Dobbiamo decidere: aggiungerle anche loro oppure scartarle. Se ci piacciono, le aggiungiamo di nuovo:

git add frutta.txt
git status

Ora l’area di lavoro è a posto: tutte le modifiche sono in staging e il commit conterrà il file completo, come lo vediamo con cat:

cat frutta.txt

Il commit

È il momento del nostro primo commit. L’opzione -m permette di dare il messaggio, cioè la descrizione, senza aprire l’editor: per i commit semplici è la strategia più efficace.

git commit -m "Aggiunto il file della frutta"

Abbiamo fissato nel tempo il primo punto della nostra linea temporale: Git ci dice che è stato modificato un file con sei righe inserite. Con un altro git status vediamo che è tutto pulito: né in staging né nell’area di lavoro ci sono modifiche.

git status

Ancora un giro

Per fissare i concetti creiamo un nuovo file, animali.txt, e modifichiamo anche frutta.txt:

nano animali.txt
git status

Git segnala un file non tracciato. Lo aggiungiamo, poi modifichiamo frutta.txt:

git add animali.txt
nano frutta.txt
git status

Ora abbiamo un file nuovo già pronto per il commit e delle modifiche a frutta.txt non ancora pronte.

Git diff

Quando le modifiche sono tante e vogliamo fare il punto, ci viene in aiuto git diff. Può essere usato in modi molto complessi, per confrontare file avanti o indietro nel tempo o su branch diversi: ci arriveremo. Nel suo uso base mostra le differenze fra quello che dobbiamo ancora preparare per il commit e la versione precedente:

git diff

L’output è molto simile a quello del comando diff, e ci dice per esempio che sono state aggiunte due righe, pesche e pere. Rispetto a diff ci sono anche indicazioni sui numeri di commit (la riga che comincia con index). Se la modifica ci va bene, la aggiungiamo e facciamo il commit:

git add frutta.txt
git status
git commit -m "Aggiunto il file degli animali e \
    modificata la frutta"
git status

Il solito rapportino ci informa su cosa abbiamo ottenuto, e un ultimo controllo ci conferma che l’area di lavoro è pulita.

La mentalità giusta

In questi video cercherò di passarvi non solo la tecnica ma anche la mentalità con cui usare Git, che è potente e a suo modo pericoloso. Il principio che raccomando sempre a studenti e clienti: lasciate sempre pulita l’area di lavoro, non lasciate mai il lavoro a metà. Git ci dà diversi strumenti oltre al commit per tenerla in ordine, ma è fondamentale essere ordinati: quando i repository diventano complessi, questa abitudine vi salverà la vita.

Git log

L’ultimo comando di oggi mostra la cronologia, cioè la struttura del repository:

git log

Chiamato senza argomenti ci dà l’elenco dei commit. Nel nostro caso due: il commit iniziale con il file frutta e il secondo con il file animali e la modifica alla frutta. I più recenti sono in cima, quindi la cronologia si legge in ordine inverso. Le opzioni per ottenere l’output in mille modi sono moltissime, ma questo formato base basta per capire la cronologia.

E qui l’ultimo principio: scrivete messaggi di commit parlanti. Quando rivedrete la cronologia, saranno l’unica cosa che vi dirà a colpo d’occhio cosa è stato fatto, dove, quando e perché. Un po’ di tempo speso per scrivere buoni messaggi ve ne farà risparmiare moltissimo.

Riepilogo dei comandi

git init
git config user.name "..."
git config user.email "..."
git status
git add nomefile
git commit -m "messaggio"
git diff
git log

Conclusione

Con questo abbiamo gli elementi per cominciare. Nei prossimi video vedremo cosa sono esattamente i branch, come usarli, e passeremo agli utilizzi più professionali. Intanto aprite la vostra Linux box, create un repository di prova e sperimentate con i comandi di oggi: sperimentate, sperimentate, sperimentate. Quando andremo avanti sarà fondamentale avere le basi solide.

Link e risorse

Sostieni il canale

PER SOSTENERE IL CANALE BASTANO UN LIKE E UN’ISCRIZIONE! ma se vuoi offrirmi un caffè, mi aiuterà a rimanere sveglio mentre registro i video 😁☕ clicca qui per scoprire come https://buymeacoffee.com/thelinuxnerd

questi link sono affiliati Amazon, acquistando i libri che ti consiglio sostieni il canale!

#linux #bash #git