Git e Version Control

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 lascia lavorare su due cose in parallelo e 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.

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 è il linguaggio comune delle squadre di sviluppo: chi non lo sa non può lavorare con gli altri.

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. Ogni commit viene firmato con nome ed email, e su GitHub quei due dati sono la tua identità pubblica dentro al 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:

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. Con nomi descrittivi e prefissi coerenti (feature/, fix/, hotfix/) capisci a cosa serve un ramo anche a distanza di mesi. Crearne e cancellarne è istantaneo: usane uno per ogni modifica e tieni 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"

In aula il primo conflitto blocca tutti, e la domanda arriva sempre uguale: l'ho rotto io? No: i marcatori con le frecce sono le due versioni della stessa riga, messe una sopra l'altra. Scegli quella che tieni, cancella il resto e fai commit. Per averne di meno, fai merge o rebase spesso dal branch principale e tieni corti i branch di feature.

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

GitHub e repository remoti

GitHub è la piattaforma più diffusa per tenere online i repository Git e lavorarci in più persone. Le alternative sono 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:

1. Crei un branch e fai le modifiche.
2. Fai push del branch su GitHub.
3. Apri una Pull Request descrivendo le modifiche.
4. I colleghi fanno code review, commentano e suggeriscono miglioramenti.
5. 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 basta il GitHub Flow: solo main, feature branch e PR.

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.