Git semplice per tutti

Questo articolo nasce dalla mia inesperienza. Il primo approccio è stato tramite VS Code e GitHub, tramite il pannello di controllo del codice sorgente. Dopo aver inizializzato la repository, notavo che veniva tracciata ogni modifica che facevo ai file, ma non sapevo a cosa servisse e cosa potevo farci.

Solo successivamente ho iniziato a capire ed imparare che quello era lo strumento che mi salvava le chiappe nel caso in cui avessi combinato qualche cavolata, oltre a permettermi di salvare il codice man mano che implementavo delle nuove funzioni.

Poi ho scoperto che dietro a quei pulsanti Commit e Sync c’era Git.

Git è un sistema che tiene traccia delle modifiche ai file nel tempo, permettendoti di tornare indietro, collaborare e gestire versioni parallele del codice.

Git è ciò che sta alla base di GitHub, GitLab, Gitea, Codeberg e così via. Poi ognuno di questi, e tutti gli altri, forniscono diverse funzionalità aggiuntive che lascio scoprire direttamente a te. Personalmente, uso GitHub per tutti i progetti. Ho anche installato in self-hosting GitLab che uso per alcuni progettini locali, ma continuo a preferire GitHub per la sua velocità di integrazione con VS Code (del resto sono entrambi di proprietà Microsoft).

Concetti fondamentali

Partiamo dalla nomenclatura che sta dietro a Git, in modo da avere le cose chiare fin da subito.

Origin, main e master

origin, main e master indicano concetti diversi che è utile non confondere.

origin è il nome convenzionale assegnato al repository remoto dal quale hai eseguito il clone. Non è una parola riservata di Git: puoi scegliere un nome diverso e uno stesso progetto può avere più remote.

Per vedere i remote configurati puoi usare:

git remote -v

main e master, invece, sono nomi di branch. Nessuno dei due ha un comportamento speciale: un branch potrebbe chiamarsi anche sviluppo, pippo o in qualsiasi altro modo.

Per molto tempo master è stato il nome predefinito del primo branch creato da Git. Dal 2020 GitHub utilizza main come nome predefinito per i nuovi repository, una scelta adottata anche da molti altri servizi e progetti. Per questo motivo puoi ancora trovare repository che usano master, soprattutto se creati in precedenza. Non è un errore: il nome del branch predefinito dipende dal progetto, dalla piattaforma e dalla configurazione locale di Git.

Quando inizializzi un repository puoi scegliere esplicitamente il nome del primo branch:

git init -b main

Puoi controllare il nome del branch corrente con:

git branch --show-current

Nel comando seguente, origin indica il repository remoto e main il branch locale che vuoi pubblicare:

git push -u origin main

L’opzione -u collega il branch locale main al corrispondente branch remoto. Dopo il primo push, normalmente potrai usare semplicemente git push e git pull senza specificare ogni volta remote e branch.

Potresti inoltre incontrare il nome origin/main: non è il branch locale main, ma il riferimento locale che rappresenta l’ultimo stato conosciuto del branch main presente sul remote origin.

Ciclo di vita di un file

Personalmente ho bisogno di immaginare le cose per capirle, quindi cerco di raccontarti cosa succede da quando modifichi un file a quando lo committi.

File modificato -> git add -> Staged -> git commit -> Committed -> git push -> Remote

Un file modificato viene aggiunto all’area “temporanea” di staging (area in cui prepari le modifiche). Poi viene effettuato il commit (al quale bisogna inserire un messaggio descrittivo) ed infine inviato (pushato/pushed) sul remote (server).

Comandi principali

Passiamo ora a quelli che sono i comandi principali e più comuni. Se usi VS Code e la sua integrazione nativa “Controllo del codice sorgente”, molti di questi comandi sono stati adattati ad icone e voci di testo.

Lavorando per hobby e passione, raramente uso comandi Git in terminale se non in certe occasioni per il setup iniziale. Se ho bisogno di fare merge o azioni più complesse mi affido all’AI.

Setup iniziale

git init                    # Inizializza un repo nella cartella corrente
git clone <url>             # Clona un repo remoto in locale
git config --global user.name "Nome"
git config --global user.email "[email protected]"

Controllare lo stato

git status                  # Mostra cosa è modificato/staged
git log                     # Storico dei commit
git log --oneline           # Storico compatto
git diff                    # Mostra le modifiche non ancora in staging
git diff --staged           # Mostra le modifiche già in staging

Staging e commit

git add <file>              # Aggiunge un file alla staging area
git add .                   # Aggiunge tutti i file modificati
git commit -m "messaggio"   # Crea un commit con messaggio
git commit --amend          # Modifica l'ultimo commit (da evitare su commit già pushati)

Remote

git remote add origin <url> # Collega il repo locale a uno remoto
git push origin <branch>    # Carica i commit sul remote
git pull                    # Scarica e integra le modifiche dal remote
git fetch                   # Scarica le modifiche senza integrarle

Annullare modifiche

git restore <file>          # Annulla modifiche non staged (attenzione: irreversibile)
git restore --staged <file> # Rimuove un file dalla staging area
git revert <commit-hash>    # Crea un nuovo commit che annulla un commit precedente
git reset --hard <hash>     # Torna a un commit eliminando tutto dopo (distruttivo)

Conclusioni

C’è altro da sapere? Ovvio che sì, ma non è questo l’articolo che andrà ad approfondire ogni aspetto di Git. A me interessava darti una panoramica iniziale per aiutarti a capire cos’è Git e come si usa nelle azioni basilari.

Per qualsiasi approfondimento fai affidamento alla documentazione ufficiale in inglese o italiano (parziale).