Git nasce nel 2005 durante lo sviluppo del kernel Linux.

Il progetto Linux era enorme, distribuito e con una quantità enorme di modifiche continue. Serviva un sistema veloce, affidabile e robusto per gestire il lavoro.

Linus Torvalds, il creatore del kernel Linux, sviluppò Git con alcuni obiettivi molto chiari:

• velocità;
• integrità dei dati;
• capacità di lavorare bene anche su progetti molto grandi;
• affidabilità.

Questa origine spiega una cosa importante: Git non nasce come strumento pensato per coccolare il principiante. Nasce per reggere lavoro serio.

Ecco perché all’inizio può sembrare un po’ ruvido. Non perché sia fatto male, ma perché è stato progettato con priorità molto pratiche.

La buona notizia è che tu non hai bisogno di conoscere ogni angolo di Git per usarlo bene. Ti basta costruire un buon modello mentale e imparare bene il nucleo essenziale.

Oggi Git è lo standard di fatto nel controllo di versione. Viene usato da freelance, team, startup, grandi aziende e progetti open source giganteschi.

Impararlo non è tempo perso su uno strumento di nicchia. È una competenza centrale nel lavoro di sviluppo.

Nota iniziale

Questa guida è pensata per chi parte da zero e vuole iniziare subito a usare Git in modo semplice, pratico e senza farsi schiacciare da spiegazioni troppo tecniche.

L’obiettivo non è trasformarti in un esperto in pochi giorni. L’obiettivo è molto più concreto: capire come funziona Git, iniziare a usarlo davvero in un progetto, evitare gli errori più comuni e costruire da subito un metodo di lavoro più ordinato.

Qui troverai i concetti fondamentali, i comandi davvero utili all’inizio e un piccolo percorso pratico per prendere confidenza con Git senza panico.

Per comprendere Git più a fondo esistono testi più completi, documentazioni ufficiali e molti altri strumenti validi. Ma soprattutto serve una cosa: pratica sul campo. Git si capisce davvero quando lo usi, sbagli, controlli, correggi e riprovi.

Se questa guida riuscirà a farti passare dal caos dei file sparsi a un modo di lavorare più chiaro e consapevole, allora avrà fatto il suo lavoro.

Perché Git ti cambia il modo di lavorare

Git è un sistema che tiene traccia delle modifiche fatte ai file di un progetto nel tempo.

Detto così sembra una definizione da manuale. In pratica significa questo: Git ti aiuta a lavorare senza perderti.

Quando non usi Git, spesso succede sempre la stessa scena. Crei una cartella progetto, poi ne fai una copia chiamata progetto-finale, poi una seconda chiamata progetto-finale-vero, poi magari progetto-finale-vero-definitivo. Dopo qualche giorno non sai più quale versione è quella giusta. Se qualcosa si rompe, non sai bene quando è successo. Se vuoi tornare indietro, ti arrangi come puoi.

Git nasce proprio per evitare questo caos.

Con Git il progetto non è più una massa confusa di file. Diventa una storia fatta di tappe. Ogni tappa importante può essere salvata con un commit. Ogni commit ha un messaggio che spiega cosa hai fatto. In questo modo non stai più lavorando alla cieca: stai costruendo una cronologia leggibile.

Git è utile anche se lavori da solo. Anzi, spesso all’inizio è utilissimo proprio per chi lavora da solo, perché mentre impari fai molte prove, sbagli, cambi idea, sistemi, rompi, ricostruisci. Avere uno strumento che ti permette di salvare tappe sensate e di recuperare una situazione stabile è una mano enorme.

Git ti dà soprattutto tre cose:

• sicurezza, perché puoi recuperare molto più spesso di quanto immagini;
• ordine, perché le modifiche vengono registrate con senso;
• libertà, perché puoi sperimentare senza la paura costante di distruggere tutto.

La cosa importante da capire fin da subito è questa: Git non è solo una collezione di comandi. È un modo di pensare il progetto nel tempo.

Git e GitHub non sono la stessa cosa

Questa è una delle confusioni più comuni.

Git e GitHub non sono la stessa cosa.

Git è il programma che lavora sul tuo computer e gestisce la cronologia del progetto.

GitHub è una piattaforma online che ospita repository Git e aggiunge funzioni come condivisione, backup remoto, collaborazione, pull request e visibilità pubblica.

Una metafora semplice può essere questa:

Con Git puoi inizializzare un repository, creare commit, fare branch, fare merge e vedere la storia del progetto anche senza internet.

Con GitHub puoi pubblicare quella storia online, avere una copia remota, collaborare con altre persone e usare il repository anche come portfolio.

Questa distinzione è importante perché ti aiuta anche a capire meglio i problemi.

Se il problema riguarda i commit, la cronologia, i branch o i file locali, stai parlando di Git.

Se il problema riguarda sincronizzazione, push, pull, repository remoto o permessi, probabilmente stai parlando di GitHub o comunque di una piattaforma remota simile.

All’inizio la cosa migliore è questa: prima impari Git bene, poi GitHub diventa molto più semplice.

Il modello mentale giusto: snapshot, commit, hash e HEAD

Per capire Git bene, devi prima capire quattro parole chiave.

Snapshot

Git ragiona per snapshot.

Uno snapshot è una fotografia dello stato del progetto in un certo momento.

Quando fai un commit, Git non sta semplicemente salvando un file come se fosse un classico “salva” di un editor. Sta registrando una tappa della storia del progetto.

Commit

Il commit è la tappa salvata.

Un commit contiene lo stato del progetto in quel momento e un messaggio che descrive l’intenzione della modifica.

Per esempio:

• Aggiunge la sezione servizi nella home
• Corregge il menu mobile
• Migliora il layout della hero su mobile

Se fai commit piccoli e chiari, la storia diventa leggibile.

Hash

Ogni commit ha un identificatore univoco chiamato hash.

Non devi impararlo a memoria. Ti basta sapere che Git usa questo codice per riferirsi in modo preciso a un commit specifico.

HEAD

HEAD è un puntatore. In parole semplici, indica dove ti trovi adesso nella cronologia.

Se sei sull’ultimo commit del branch main, HEAD punta lì.

Se fai un nuovo commit, HEAD si sposta avanti.

Se cambi branch, HEAD segue il branch su cui ti trovi.

Riassunto semplice

• snapshot = fotografia;
• commit = tappa salvata;
• hash = identificatore del commit;
• HEAD = punto in cui ti trovi adesso.

Quando questi concetti iniziano a essere chiari, Git smette di sembrare magia nera.

Working tree, staging area e repository

Uno dei punti più importanti per un principiante è capire che in Git esistono tre zone.

Working tree

Il working tree è la tua cartella di lavoro reale. È il posto dove modifichi i file.

Per esempio:

• index.html
• style.css
• main.js

Staging area

La staging area è una zona intermedia.

Qui prepari le modifiche che vuoi inserire nel prossimo commit.

È come un vassoio dove metti solo le cose pronte per essere spedite.

Repository

Il repository è la cronologia vera e propria dei commit già salvati.

Perché la staging area è importante

All’inizio può sembrare una complicazione inutile. In realtà è uno dei superpoteri di Git.

Ti permette di decidere con precisione cosa entra nel prossimo commit.

Esempio molto realistico:

Hai modificato style.css per sistemare la hero. Hai anche toccato main.js, ma lì stai ancora facendo una prova che non funziona bene.

Con Git puoi mettere in staging solo style.css e fare un commit pulito sul layout. main.js resta fuori finché non è pronto.

Questo ti permette di fare commit più chiari e una cronologia molto più leggibile.

Immagine mentale utile

Pensa così:

• working tree = scrivania;
• staging area = vassoio prima della spedizione;
• repository = archivio.

Se questa immagine ti entra bene in testa, metà della confusione iniziale sparisce.

Installazione e configurazione iniziale

Installare Git oggi è abbastanza semplice.

Su Windows puoi usare Git for Windows.

Su macOS puoi usare Homebrew o gli strumenti Apple.

Su Linux lo trovi quasi sempre nei repository della distribuzione.

La prima cosa da fare dopo l’installazione è controllare che Git funzioni.

git --version

Poi conviene impostare almeno nome ed email, perché Git userà questi dati nei commit.

git config --global user.name "Il Tuo Nome"
git config --global user.email "tuamail@example.com"
git config --global init.defaultBranch main

Se usi Visual Studio Code, può essere utile anche impostarlo come editor predefinito:

git config --global core.editor "code --wait"

Per vedere la configurazione corrente:

git config --list

Questa fase è semplice ma importante. Meglio fare queste cose subito invece di arrivare al primo commit e scoprire che Git si lamenta perché mancano nome ed email.

Il primo repository da zero

Qui iniziamo davvero.

Immagina di avere una cartella con un piccolo progetto, magari un sito statico.

Entri nella cartella e inizializzi Git.

cd mio-progetto
git init

Da quel momento quella cartella non è più solo una cartella. È diventata un repository Git.

Subito dopo conviene controllare lo stato:

git status

Questo comando è uno dei più importanti in assoluto. Ti dice:

• su quale branch sei;
• quali file sono nuovi;
• quali sono modificati;
• quali sono pronti per il commit.

Poi puoi aggiungere i file e fare il primo commit:

git add .
git commit -m "Primo commit: struttura iniziale del progetto"

Cosa hai fatto davvero

Hai fatto quattro cose fondamentali:

• hai creato un repository locale;
• hai detto a Git di osservare i file del progetto;
• hai preparato quei file per il commit;
• hai salvato il primo snapshot nella cronologia.

Questo passaggio va capito bene, perché lo ripeterai in ogni progetto futuro.

Il ciclo base quotidiano: status, add, commit, log

La maggior parte del lavoro quotidiano con Git gira attorno a pochi comandi.

Se impari bene questi, hai già il cuore dell’uso pratico.

git status

Ti mostra la situazione attuale.

È il comando che ti impedisce di lavorare bendato.

Usalo spesso.

git add

git add style.css

Serve a preparare le modifiche per il prossimo commit.

Puoi usarlo su file specifici oppure, se ha senso, su tutto il progetto.

git add .

Ma attenzione: git add . non è il male assoluto, però usato sempre senza pensare può mischiare modifiche che sarebbe meglio tenere separate.

git commit

git commit -m "Migliora il layout mobile della hero"

Salva nella cronologia le modifiche che hai preparato in staging.

git log

git log --oneline --graph --decorate --all

Mostra la storia del progetto in modo compatto e leggibile.

Il flusso mentale giusto

Questa piccola abitudine cambia moltissimo la qualità del lavoro.

Come scrivere messaggi di commit che abbiano senso

Il messaggio di commit è l’etichetta della fotografia che stai salvando.

Se il messaggio è chiaro, il futuro te capirà subito cosa hai fatto. Se è vago, la cronologia diventa un pantano.

Messaggi buoni

• Aggiunge la sezione servizi nella home
• Corregge il bug del menu mobile
• Migliora il contrasto dei pulsanti nel footer
• Riorganizza i file della navbar

Messaggi deboli

• update
• fix
• varie cose
• tentativo
• boh

Regola pratica

Un commit dovrebbe raccontare una sola intenzione.

Se per descriverlo ti viene da dire “ho fatto un po’ di tutto”, probabilmente hai accumulato troppe modifiche insieme.

Commit più piccoli e più chiari quasi sempre battono commit enormi e confusi.

.gitignore spiegato bene

.gitignore è il file in cui dici a Git quali file o cartelle ignorare.

Non tutto deve entrare nella cronologia.

In un progetto frontend tipico, spesso conviene ignorare cose come:

node_modules/
dist/
.env
.DS_Store
Thumbs.db
.vscode/

Perché è importante

Un buon .gitignore:

• tiene pulita la cronologia;
• evita rumore inutile;
• riduce i rischi;
• impedisce di versionare file sensibili per sbaglio.

Attenzione importante

Se un file è già stato tracciato, aggiungerlo dopo a .gitignore non basta a farlo sparire dal repository.

In quel caso devi prima rimuoverlo dall’indice:

git rm --cached nomefile

Poi fai un commit.

Questo punto confonde tantissimi principianti.

Branch: cosa sono davvero

Un branch è una linea di lavoro separata.

Ti permette di sviluppare una modifica senza sporcare subito il branch principale, che di solito si chiama main.

Per esempio, se vuoi provare una nuova navbar mobile, invece di lavorare direttamente su main puoi creare un branch dedicato.

git switch -c feature/navbar-mobile

Da quel momento lavori lì dentro.

Perché servono

I branch ti permettono di:

• sperimentare senza caos;
• separare meglio il lavoro;
• tenere main più pulito;
• unire il risultato solo quando è pronto.

Nomi utili per i branch

• feature/navbar-mobile
• fix/footer-link
• refactor/cards-layout
• docs/setup-guide

Evita nomi confusi tipo prova, test2, nuovo, boh.

Una cosa utile da sapere

I branch non sono copie pesanti del progetto. Sono puntatori intelligenti alla storia. Per questo crearli è leggero e normale.

Merge e conflitti senza panico

Quando hai finito di lavorare su un branch, puoi unirlo a main.

Questo si chiama merge.

git switch main
git merge feature/navbar-mobile

Se Git riesce a combinare tutto da solo, il merge fila via tranquillo.

Se invece due linee di lavoro hanno modificato la stessa parte di uno stesso file in modi incompatibili, nasce un conflitto.

Il conflitto non è una tragedia

Il conflitto non è Git che si rompe.

È Git che ti dice:

Qui non posso decidere da solo. Dimmi tu quale versione tenere.

Nel file vedrai marcatori di questo tipo:

<<<<<<< HEAD
<nav class="main-nav dark">
=======
<nav class="main-nav glass">
>>>>>>> feature/header-style

Tu devi leggere, capire le due versioni e scegliere cosa tenere oppure combinarle manualmente.

Poi salvi il file, lo aggiungi di nuovo e completi il processo:

git add index.html
git commit

Come ridurre i conflitti

• fai branch piccoli;
• non lasciare i branch aperti per secoli;
• integra spesso;
• fai commit chiari.

Più il lavoro è ordinato, meno i conflitti fanno paura.

Remoti: clone, fetch, pull e push

Un remoto è una copia del repository ospitata altrove, per esempio su GitHub.

Il nome convenzionale del remoto principale è spesso origin.

Collegare un repository locale a GitHub

git remote add origin https://github.com/tuonome/nome-repo.git
git remote -v
git push -u origin main

I quattro verbi da capire bene

clone

git clone https://github.com/utente/progetto.git

Scarica in locale un repository remoto già esistente.

fetch

git fetch origin

Aggiorna le informazioni dal remoto, ma senza integrare automaticamente nel branch corrente.

È molto utile perché ti fa vedere prima e decidere poi.

pull

git pull origin main

Scarica e integra nel branch corrente.

In pratica è fetch più integrazione.

push

git push origin main

Pubblica sul remoto i commit che hai fatto in locale.

Consiglio pratico

All’inizio non usare pull come un pulsante automatico premuto a occhi chiusi. Meglio capire cosa stai facendo. A volte fetch prima di integrare ti dà più controllo e meno ansia.

Tornare indietro: restore, reset e revert

Questa è una delle zone che spaventa di più i principianti.

In realtà basta capire che questi tre comandi non fanno la stessa cosa.

restore

Serve soprattutto a scartare modifiche locali o a ripristinare un file.

git restore style.css

Se hai pasticciato un file e vuoi tornare alla versione precedente, restore è spesso la scelta più semplice.

reset

reset è più potente e più delicato.

Può spostare il puntatore della cronologia e, a seconda dell’opzione usata, influenzare staging area e working tree.

git reset --soft HEAD~1
git reset --hard HEAD~1

• --soft torna indietro ma mantiene il lavoro pronto;
• --hard torna indietro in modo drastico e può eliminare modifiche non salvate.

Quindi: utile, ma da usare con cervello.

revert

revert è diverso.

Non cancella un commit dalla storia. Crea un nuovo commit che annulla l’effetto del commit scelto.

git revert abc1234

Per questo è spesso la scelta più sicura quando la cronologia è già stata pubblicata.

Schema mentale rapido

• restore = scarto o ripristino file;
• reset = riposiziono la cronologia;
• revert = annullo un commit senza riscrivere il passato.

Reflog: il paracadute nascosto

git reflog è uno dei comandi più rassicuranti di Git.

Registra i movimenti di HEAD e di altri riferimenti. In pratica ti aiuta a ritrovare punti della cronologia che sembravano spariti.

Molte volte quando uno dice “ho perso tutto”, Git risponde: “forse no”.

Esempio

git reflog
git reset --hard HEAD@{2}

Con reflog guardi i movimenti recenti. Poi puoi decidere di tornare a un punto precedente.

Non è magia eterna e non sostituisce il buon senso, ma sapere che esiste cambia tantissimo il rapporto psicologico con Git.

Errori classici dei principianti

Chi inizia con Git inciampa spesso negli stessi punti.

1. Fare commit giganteschi. Se in un solo commit metti HTML, CSS, JavaScript, immagini, prove e cambiamenti scollegati, poi capire o correggere diventa molto più difficile.
2. Usare messaggi vaghi. update non racconta niente.
3. Lavorare sempre su main. Per modifiche piccole può anche capitare, ma come regola generale è molto meglio usare branch sensati.
4. Dimenticare .gitignore. Poi ti ritrovi a tracciare roba inutile o sensibile.
5. Usare pull senza capire. Meglio sapere almeno mentalmente che cosa sta entrando nel tuo progetto.
6. Usare reset –hard con leggerezza. Quel comando non è una caramella.
7. Andare nel panico davanti a un conflitto. Il conflitto non è la fine del mondo. È una scelta manuale che Git ti chiede.
8. Non controllare status. git status è il tuo cruscotto. Se lo ignori, lavori mezzo bendato.

Mini laboratorio guidato

Facciamo un piccolo percorso realistico.

Immagina di avere una cartella con questi file:

• index.html
• style.css
• main.js
• images/

Passo 1: inizializza Git

cd sito-vetrina
git init
git status

Passo 2: crea .gitignore se serve

Per esempio, se è un progetto con build o dipendenze:

node_modules/
dist/
.env

Passo 3: primo commit

git add .
git commit -m "Primo commit: struttura iniziale del sito"

Passo 4: fai una modifica mirata

Immagina di migliorare il titolo hero e il padding della navbar.

Controlla cosa è cambiato:

git status
git diff

Se tutto è coerente:

git add index.html style.css
git commit -m "Aggiorna hero e migliora spacing della navbar"

Passo 5: crea un branch per una nuova funzione

git switch -c feature/testimonials

Aggiungi una nuova sezione e fai un commit dedicato:

git add index.html
git commit -m "Aggiunge markup sezione testimonials"

Poi magari aggiungi lo stile:

git add style.css
git commit -m "Aggiunge stile responsive per testimonials"

Passo 6: torna su main e fai merge

git switch main
git merge feature/testimonials

Passo 7: collega GitHub e fai push

git remote add origin https://github.com/utente/sito-vetrina.git
git push -u origin main

Cosa hai fatto davvero

Hai già usato il cuore pratico di Git:

• init;
• status;
• add;
• commit;
• branch;
• merge;
• push.

Se rifai questo laboratorio due o tre volte su progetti piccoli, inizi davvero a sentirti meno spaesato.

Checklist di sopravvivenza

Prima di fare commit

• Ho capito quali modifiche voglio davvero salvare.
• Questo commit racconta una sola intenzione.
• Il messaggio è chiaro.
• Non sto includendo file inutili o sensibili.
• Ho controllato git status o git diff.

Prima di fare push

• Sto lavorando sul branch giusto.
• La cronologia è sensata.
• Non sto pubblicando roba rotta per sbaglio.
• So cosa sto mandando sul remoto.

Quando qualcosa va storto

• Non panico.
• Leggo git status.
• Cerco di capire dove sono: working tree, staging, repository o remoto.
• Se ho paura di perdere qualcosa, controllo reflog.
• Se la cronologia è già pubblica, valuto revert prima di fare danni peggiori.

Glossario essenziale

Repository

il progetto con la sua cronologia Git.

Commit

una tappa salvata nella storia.

Branch

una linea di sviluppo separata.

Merge

unione di due linee di lavoro.

Remote

copia del repository ospitata altrove.

Origin

nome convenzionale del remoto principale.

HEAD

puntatore alla posizione attuale nella cronologia.

Hash

identificatore univoco di un commit.

Staging area

zona intermedia tra modifiche locali e commit.

Working tree

i file reali su cui stai lavorando.

Metodo pratico: manuale con criterio + AI in assistenza

Il punto non è lasciare tutto in mano all'AI. Il punto è usare l'AI come copilota operativo, mentre tu tieni la direzione: intenzione del commit, confini, rischi, ordine logico.

Regola semplice: prima chiedi analisi e proposta, poi approvi azione. Così eviti commit sporchi, push impulsivi e correzioni dolorose.

Schema operativo: cosa fai tu e cosa delegi

Workflow completo su progetto reale

1. Imposta il progetto: fai inizializzazione e verifica stato iniziale.

   Inizializza il repository Git in questa cartella, configura main se necessario e spiegami in modo sintetico cosa hai fatto.

2. Separa i lavori per argomento: prima capire, poi toccare staging.

   Analizza le modifiche e dividile per blocchi: contenuti guida, stile, script, altro.

3. Prepara commit pulito: un intento unico, niente rumore.

   Prepara un commit solo dei file legati alla guida Git, escludi il resto, poi mostrami file staged, diff staged e messaggio commit proposto.

4. Gestisci conflitti in sicurezza: mai scorciatoie distruttive.

   Guidami nella risoluzione dei conflitti mantenendo le parti utili. Non usare reset --hard o comandi distruttivi.

5. Fai quality gate prima del push: solo se tutto è coerente.

   Prima del push fai checklist rischi: branch corretto, commit sensati, diff pulito, nessun file sensibile, working tree pulito. Poi procedi.

Esempio concreto: dal manuale all'AI

Manuale classico: git status -> git add -p -> git diff --staged -> git commit -> git push.

Versione assistita: chiedi lo stesso flusso in linguaggio naturale, ma imponi sempre vincoli chiari su scope e sicurezza.

Prompt pratici da usare subito

Controlla lo stato Git del progetto e riassumilo in 3 righe.

Prepara un commit solo dei file della guida Git, escludi tutto il resto e mostrami il diff.

Guidami nella risoluzione di questo conflitto senza usare comandi distruttivi.

Prima di pushare fammi checklist rischi e poi procedi.

Regola d'oro finale: delega velocità e ripetizione, non la comprensione. Se resti tu a guidare la logica, l'AI ti fa lavorare meglio, non a caso.

Nota finale

Arrivato qui non hai visto tutto Git, e va bene così.

Hai visto la parte più utile per iniziare davvero: capire la logica di Git, usare il flusso base, fare commit più puliti, lavorare con più ordine, evitare alcuni errori classici e recuperare con più calma quando qualcosa va storto.

Per andare più a fondo esistono argomenti che qui sono stati solo accennati o lasciati fuori, come rebase, stash, cherry-pick, tag, pull request avanzate e altri strumenti più specialistici. Sono utili, ma non servono per muovere i primi passi in modo solido.

La verità è semplice: Git non si impara leggendo una volta sola. Si impara usandolo. Più farai piccoli esperimenti su progetti veri, più i concetti ti sembreranno naturali. E più i comandi smetteranno di sembrare magia nera e inizieranno a diventare strumenti normali di lavoro.

Non serve sapere tutto subito. Serve iniziare bene. E iniziare bene, con Git, vuol dire meno confusione, meno panico e molto più controllo su quello che stai costruendo.

Questa guida vuole fare esattamente questo: darti una base pratica, chiara e umana da cui partire.

Adesso il passo successivo non è rileggere tutto dieci volte. È aprire un progetto, inizializzare Git e cominciare a usarlo davvero.