Come imparare Git: piano di studio, esercizi, documentazione e pratica

Git si impara con le mani, non leggendo. Per lavorare con sicurezza in un team bastano circa venti comandi e tre idee: il commit è un'istantanea del progetto, il ramo è un puntatore a un commit, e il repository remoto è semplicemente un'altra copia della cronologia. Qui sotto trovate un piano di studio di Git per fasi, con esercizi, risorse gratuite e criteri per capire quando una fase è completata.

Il piano è pensato per un principiante che sa già usare il terminale almeno a livello di cd e ls. Se non è così, dedicate una serata alle basi della riga di comando: senza di esse imparare Git è molto più difficile.

Perché conviene studiare Git in modo sistematico

Molte persone per anni usano cinque comandi copiati da un'istruzione altrui e vanno nel panico al primo conflitto o davanti al «detached HEAD». Quasi sempre il motivo è uno solo: manca un modello mentale, cioè non si capisce che cosa un comando cambia nella cronologia e nei file.

Lo studio sistematico ripaga in fretta. Smettete di avere paura di sperimentare, perché sapete come tornare indietro; risolvete i conflitti con calma; tenete una cronologia ordinata, che i revisori e i selezionatori possono leggere. Su Git si viene verificati ai colloqui in quasi tutte le professioni IT, dal frontend al DevOps fino all'analisi dei dati.

Fase 1. Le basi: repository, indice, commit

Obiettivo della prima fase: capire il ciclo base e le tre aree di Git — directory di lavoro, indice e repository. Richiede 2–4 giorni di circa un'ora ciascuno.

• Installazione e prima configurazione: git config --global user.name, user.email, ramo predefinito main.
• Creazione di un repository: git init.
• Il ciclo git status → git add → git commit; l'aggiunta selettiva con git add -p.
• Consultazione della cronologia: git log --oneline, git diff, git diff --staged, git show.
• Il file .gitignore: che cosa non deve finire nel repository.

Esercizio. Create un repository per le vostre note o per un piccolo script. Fate 15–20 commit, ognuno con una sola modifica logica e un messaggio chiaro. Dopo ogni comando eseguite git status e spiegate a voi stessi che cosa è cambiato.

Fase completata quando sapete dire, senza suggerimenti, in cosa l'output di git diff differisce da quello di git diff --staged, e riuscite a committare solo una parte dei file modificati.

Fase 2. Rami e fusione

I rami sono il cuore di Git e la principale fonte di paura per i principianti. Qui conta non memorizzare i comandi, ma imparare a immaginare il grafo dei commit. Dedicate a questa fase circa una settimana.

• Creazione e cambio di ramo: git branch, git switch, git switch -c.
• Che cos'è HEAD e lo stato di detached HEAD.
• Fusione: git merge, fast-forward e merge commit, il flag --no-ff.
• Conflitti: i marcatori <<<<<<< e >>>>>>>, git merge --abort.
• Visualizzazione: git log --oneline --graph --all.

Esercizio. Create due rami da main e modificate in ciascuno la stessa riga di uno stesso file. Unite i rami uno dopo l'altro, generate il conflitto e risolvetelo. Ripetete finché il processo non diventa noioso.

In questa fase aiuta molto un simulatore interattivo di Git, di cui parliamo più avanti: mostra il grafo dopo ogni comando e costruisce rapidamente l'intuizione.

Fase 3. Repository remoti e lavoro di squadra

Obiettivo: imparare a lavorare con un server come si fa nei team. Serve un account su GitHub, GitLab o un altro hosting Git. Durata: circa una settimana.

• Collegamento e clonazione: git remote add, git clone, accesso con chiave SSH.
• Sincronizzazione: git push, git push -u, git fetch, git pull e la differenza tra loro.
• Rami di tracciamento remoto come origin/main.
• Fork, rami di funzionalità e pull request con revisione del codice.
• Processi di team: GitHub Flow, Git Flow, trunk-based development.

Esercizio. Lavorate con un unico repository da due «computer»: clonatelo in due cartelle diverse. Fate commit in una, inviate il push, recuperate le modifiche nell'altra. Provocate una situazione in cui il push viene rifiutato perché il server è più avanti, e capite perché.

git clone git@github.com:you/sandbox.git copia-a
git clone git@github.com:you/sandbox.git copia-b
cd copia-a && echo "da A" >> notes.txt && git commit -am "Modifica da A" && git push
cd ../copia-b && echo "da B" >> notes.txt && git commit -am "Modifica da B"
git push          # rifiutato: il server è più avanti
git pull          # arriva la modifica di A, risolviamo il conflitto in notes.txt
git push

Questo breve scenario riproduce la situazione più frequente in un team. Analizzate l'output di ogni comando: perché il push è stato rifiutato, che cosa è comparso in origin/main dopo il fetch, da dove viene il merge commit. Poi ripetete la stessa cosa con git pull --rebase e confrontate i grafi con git log --oneline --graph --all.

Ancora meglio: trovate un compagno e realizzate insieme un piccolo progetto con pull request. Così capirete davvero la revisione, i conflitti e gli accordi sui rami.

Fase 4. Annullare gli errori

Questa fase trasforma Git da fonte di ansia in una rete di sicurezza. Richiede 3–5 giorni.

• git restore e git restore --staged — annullamento sui file e nell'indice.
• git commit --amend — correggere l'ultimo commit.
• git reset nelle modalità --soft, --mixed, --hard.
• git revert — annullamento sicuro di un commit già pubblicato.
• git reflog — recupero dei commit «persi».

Esercizio. Fate alcuni commit, eseguite git reset --hard HEAD~3 e recuperateli con il reflog. Annullate un commit in un ramo «condiviso» con revert e guardate come appare nella cronologia.

Fase 5. Strumenti avanzati

Si imparano quando servono, ma conviene sapere in anticipo che esistono.

Simulatori di Git: dove fare pratica

Un simulatore è utile perché offre una sandbox sicura e mostra subito il risultato. Alcune opzioni gratuite:

• Learn Git Branching (learngitbranching.js.org) — il miglior simulatore sui rami. Livelli con compiti, grafo dei commit animato. L'interfaccia è in inglese, ma i comandi sono quelli standard. Copre commit, branch, merge, rebase, cherry-pick, rebase interattivo e lavoro con i remote.
• Oh My Git! — un gioco gratuito e open source in cui i comandi Git sono rappresentati da carte, mentre sotto il cofano gira un Git vero.
• Un repository di prova — il simulatore più sottovalutato. Create una cartella git-sandbox e rompete tutto quello che volete: non c'è niente da perdere.

I simulatori sviluppano molto bene la comprensione del grafo, ma non sostituiscono un progetto reale: non ci sono file veri, editor, conflitti nel codice né IDE. Usateli come complemento.

Documentazione di Git e manuali

La documentazione ufficiale di Git si trova su git-scm.com. Lì è disponibile gratuitamente anche il libro Pro Git di Scott Chacon e Ben Straub. È il miglior manuale su Git: i primi tre capitoli (fondamenti, rami) sono indispensabili, il capitolo sulla struttura interna di Git serve a chi vuole capire fino in fondo il modello dei dati.

La guida integrata è sempre a portata di mano: git help <comando> apre il manuale completo, git <comando> -h mostra l'elenco breve dei flag. La documentazione di Git è asciutta ma precisa; abituatevi a consultarla invece di fidarvi della prima risposta trovata in rete.

git help rebase        # manuale completo
git switch -h          # riepilogo rapido dei flag
git help -g            # elenco delle guide concettuali (gitworkflows, gittutorial…)

Utili sono anche le guide gittutorial e giteveryday: fanno parte della distribuzione standard di Git e si aprono con git help.

Da soli o con un corso

Si può imparare Git da soli: il libro, il simulatore e un repository di prova offrono tutto il necessario. La difficoltà sta altrove: senza struttura è facile restare bloccati nella teoria oppure, al contrario, accumulare comandi senza capirli, e senza un riscontro nessuno vi dice che tenete una cronologia disordinata.

Un corso di Git è utile se volete percorrere la strada in modo rapido e ordinato: dal primo commit fino alla pull request in un repository reale, con esercizi a ogni passo. Nella scelta guardate non la durata, ma la quota di pratica: ci sono esercizi con conflitti, annullamento degli errori, lavoro di squadra e un progetto finale?

Quanto tempo serve per imparare Git

I numeri sono indicativi: conta la regolarità. Un'ora ogni giorno dà più risultati delle maratone del fine settimana una volta al mese.

Errori tipici nello studio di Git

• Studiare solo con il GUI. I client grafici sono comodi, ma nascondono il modello. Prima capite la riga di comando, poi scegliete lo strumento che preferite.
• Memorizzare i flag. Bisogna memorizzare le idee: i flag si trovano sempre con -h.
• Avere paura di rompere le cose. Finché non avete fatto un reset --hard e non vi siete ripresi, non sapete quanto Git vi protegga.
• Saltare i repository remoti. Un Git solo locale, senza push, pull e pull request, è metà del mestiere.
• Commit «fix» e «update». L'abitudine a scrivere messaggi sensati è più facile da costruire fin dall'inizio.

Progetto finale per consolidare

La verifica migliore è una simulazione di sviluppo di squadra. Create un repository, proteggete il ramo main da push diretti, invitate un compagno o lavorate da due account. Ogni attività sia un ramo di funzionalità separato con pull request e revisione; provocate almeno un conflitto, annullate almeno un commit sbagliato con revert, contrassegnate una release con un tag.

Dopo un progetto così Git smette di essere una raccolta di formule magiche. Vedete il grafo, capite le conseguenze dei comandi e siete pronti alle domande del colloquio.

Riepilogo

Lo studio efficace di Git segue un ordine preciso: ciclo base, rami, lavoro con il server, annullamento degli errori, poi gli strumenti avanzati. Il simulatore aiuta a vedere il grafo, Pro Git e la documentazione ufficiale danno profondità, mentre un repository di prova e un progetto di squadra trasformano le conoscenze in competenza. È proprio questo il percorso — dal primo git init fino alla pull request nel progetto finale — su cui è costruito il corso di Git di Skillaria.