Git e Version Control

Aggiornato: Aprile 2026 9 min di lettura

Cos'è Git

Git è un sistema di version control distribuito creato da Linus Torvalds nel 2005. Permette di tracciare ogni modifica al codice sorgente, tornare a versioni precedenti, lavorare in parallelo su funzionalità diverse e collaborare con altri sviluppatori senza sovrascrivere il lavoro altrui.

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

Dopo aver installato Git, la prima operazione è configurare nome e email, che verranno associati a 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.

Comandi base: add, commit, push, pull

Il flusso di lavoro quotidiano con Git ruota attorno a quattro operazioni fondamentali:

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) permettono di lavorare su funzionalità separate senza toccare il codice principale. Ogni branch è un puntatore leggero a un commit specifico.

# 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.

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 dice a Git quali file e cartelle ignorare. È fondamentale per escludere dipendenze, file di configurazione locale e dati sensibili.

# 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 (PR) è il meccanismo con cui si propone l'integrazione di un branch nel codice principale. È il cuore del workflow collaborativo:

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 branching strutturato che definisce branch specifici per ogni fase del ciclo di sviluppo:

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 è lo strumento indispensabile per qualsiasi progetto web: dalla gestione del codice HTML e CSS fino al deploy di applicazioni JavaScript complesse.