Git e Version Control

Aggiornato: Aprile 2026 9 min di lettura

Cos'è Git

Git è un sistema di controllo di versione distribuito, scritto da Linus Torvalds nel 2005. Tiene traccia di ogni modifica al codice, ti fa tornare a com'era ieri, ti permette di lavorare su due cose in parallelo e di scrivere codice insieme ad altri senza sovrascrivervi a vicenda. La ragione per cui vale la pena impararlo la capisci la prima volta che rompi qualcosa e la recuperi in dieci secondi.

Punti chiave

Git traccia ogni modifica al codice: puoi sempre tornare indietro a una versione precedente.
È distribuito: ogni sviluppatore ha una copia completa della storia del progetto e lavora anche offline.
Il flusso quotidiano si basa su quattro comandi: add, commit, push, pull.
I branch permettono di sviluppare funzionalità in parallelo senza toccare il codice stabile.
GitHub e le Pull Request rendono possibile la collaborazione e la code review in team.

A differenza dei sistemi centralizzati (come SVN), in Git ogni sviluppatore possiede una copia completa della storia del progetto. Questo lo rende veloce, affidabile e utilizzabile anche offline.

"Git non è solo un tool: è il linguaggio comune di ogni team di sviluppo moderno. Non conoscerlo significa non poter collaborare."

Setup iniziale

Appena installato, la prima cosa è dire a Git chi sei: nome ed email finiscono in ogni commit.

git config --global user.name "Il Tuo Nome"
git config --global user.email "email@esempio.it"

# Verificare la configurazione
git config --list

# Inizializzare un nuovo repository
git init

# Clonare un repository esistente
git clone https://github.com/utente/progetto.git

git init crea un nuovo repository locale nella cartella corrente, mentre git clone scarica un repository remoto con tutta la sua storia. La configurazione di nome ed email non è un dettaglio formale: ogni commit viene firmato con questi dati e su GitHub diventano la tua identità pubblica all'interno del progetto. Conviene usare la stessa email anche sull'account GitHub, così i contributi vengono attribuiti correttamente al tuo profilo.

Comandi base: add, commit, push, pull

Il lavoro di tutti i giorni gira intorno a quattro comandi:

Comando	Azione	Esempio
`git add`	Aggiunge file alla staging area	`git add index.html style.css`
`git commit`	Salva uno snapshot del codice	`git commit -m "Aggiunta navbar"`
`git push`	Invia i commit al repository remoto	`git push origin main`
`git pull`	Scarica e integra le modifiche remote	`git pull origin main`
`git status`	Mostra lo stato dei file	`git status`
`git log`	Visualizza la cronologia dei commit	`git log --oneline`

Messaggi di commit efficaci: scrivi messaggi brevi ma descrittivi in modo imperativo: "Aggiungi validazione form", "Correggi bug nel calcolo totale". Un buon messaggio spiega il perché della modifica, non solo il cosa.

Branching

I branch (rami) ti fanno lavorare su una cosa nuova senza toccare il codice che funziona. Tecnicamente un branch è solo un puntatore a un commit, e questa leggerezza è il motivo per cui in Git si creano senza pensarci.

# Creare un nuovo branch
git branch feature/nuova-navbar

# Spostarsi su un branch
git checkout feature/nuova-navbar

# Creare e spostarsi in un solo comando
git checkout -b feature/nuova-navbar

# Elencare tutti i branch
git branch -a

# Eliminare un branch già mergiato
git branch -d feature/nuova-navbar

La convenzione più diffusa prevede un branch main (o master) stabile, con branch separati per ogni feature, bugfix o esperimento. Adottare nomi descrittivi e prefissi coerenti (feature/, fix/, hotfix/) rende immediatamente leggibile lo scopo di ogni ramo, anche a distanza di mesi. Poiché in Git i branch sono solo puntatori, crearne e cancellarne è un'operazione istantanea: usali liberamente per isolare ogni singola modifica e tenere pulito il ramo principale.

Merge e conflitti

Il merge unisce le modifiche di un branch in un altro. Quando due branch modificano le stesse righe di un file, Git segnala un conflitto che va risolto manualmente.

# Merge del branch feature in main
git checkout main
git merge feature/nuova-navbar

# In caso di conflitto, Git segna il file così:
<<<<<<< HEAD
codice del branch corrente
=======
codice del branch in merge
>>>>>>> feature/nuova-navbar

# Dopo aver risolto: salvare il file, poi
git add file-risolto.html
git commit -m "Risolto conflitto sulla navbar"

Per evitare conflitti frequenti, è buona pratica fare merge o rebase regolarmente dal branch principale e mantenere i branch di feature brevi e focalizzati.

.gitignore

Il file .gitignore elenca cosa Git deve ignorare. Serve per le dipendenze, per i file di configurazione locale e soprattutto per le chiavi e le password: una chiave finita in un commit pubblico resta nella storia del repository anche dopo che l'hai cancellata dal file.

# Dipendenze
node_modules/
vendor/

# File di ambiente
.env
.env.local

# File di sistema
.DS_Store
Thumbs.db

# Build e output
dist/
build/
*.min.js
*.min.css

# IDE
.vscode/
.idea/

Attenzione: .gitignore funziona solo per file non ancora tracciati. Se hai già committato un file e poi lo aggiungi a .gitignore, devi prima rimuoverlo dal tracking con git rm --cached nomefile.

GitHub e repository remoti

GitHub è la piattaforma più diffusa per ospitare repository Git, collaborare su progetti open-source e gestire il ciclo di vita del software. Alternative popolari includono GitLab e Bitbucket.

Repository pubblici: visibili a tutti, ideali per open-source e portfolio.
Repository privati: accessibili solo ai collaboratori invitati.
Fork: copia di un repository altrui sul proprio account, per proporre modifiche.
Issues: sistema di ticketing per segnalare bug e richiedere feature.
Actions: CI/CD integrato per automatizzare test, build e deploy.

Per collegare un repository locale a GitHub:

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

Pull Request

La Pull Request è il modo di proporre che il tuo ramo entri nel codice principale, e insieme il posto dove si discute il codice prima che ci entri:

Crei un branch e fai le modifiche.
Fai push del branch su GitHub.
Apri una Pull Request descrivendo le modifiche.
I colleghi fanno code review, commentano e suggeriscono miglioramenti.
Dopo l'approvazione, la PR viene mergiata nel branch principale.

Una buona PR ha un titolo chiaro, una descrizione delle modifiche, screenshot se ci sono cambiamenti visivi e riferimenti alle issue correlate.

Git Flow

Git Flow è un modello di rami più strutturato, con un ramo dedicato a ogni fase del ciclo di sviluppo. Su un progetto di una persona è sovrastruttura; su una squadra con rilasci programmati serve:

main: contiene solo codice stabile e rilasciato in produzione.
develop: branch di integrazione dove confluiscono tutte le feature completate.
feature/*: branch per lo sviluppo di nuove funzionalità, partono da develop.
release/*: preparazione di una nuova release, bug fix finali e aggiornamento versione.
hotfix/*: correzioni urgenti in produzione, partono da main.

Per progetti più piccoli o team agili, il GitHub Flow (più semplice: solo main + feature branch + PR) è spesso preferibile. L'importante è scegliere un workflow e seguirlo con coerenza all'interno del team.

Git conviene metterlo sotto qualsiasi cosa, anche un sito di cinque pagine di HTML e CSS: costa cinque minuti e il giorno in cui vuoi tornare alla versione di tre settimane fa è l'unica cosa che ti salva. Per il codice JavaScript e per i progetti veri diventa il centro del lavoro.

Vuoi imparare ad applicarlo davvero?

Scopri i corsi e la formazione di Federico Boggia su AI, dati e digitale.

Vai ai corsi