Git per principianti: init, add, commit, push, pull spiegati con esempi veri

Hai un progetto che cambia ogni giorno. HTML, CSS, PHP, magari un database. Ogni modifica è un rischio: un fix ne rompe un altro, torni indietro a memoria, i file si accumulano in cartelle tipo sito_definitivo_v3_finale_vero.zip. Lo vediamo continuamente da chi arriva da noi con un e-commerce WordPress fatto a metà e senza storico delle modifiche.

Noi, di Meteora Web, usiamo Git dalla fondazione, nel 2017. Non perché sia di moda, ma perché ci fa risparmiare ore ogni settimana. E quando gestisci clienti in tutta Italia, ogni ora conta. In questa guida prendiamo i cinque comandi fondamentali — init, add, commit, push, pull — e li spieghiamo con esempi che puoi copiare e incollare. Niente slides aziendali, niente storia di Linux. Solo roba che usi subito.

Perché Git non è un optional — il problema che risolve

Immagina di lavorare su un sito. Modifichi il footer. Poi il cliente dice: «Il footer vecchio andava meglio». Con Git scrivi git checkout . e torni indietro. Senza Git? Cerchi nel cestino, nei backup manuali, oppure riscrivi tutto. Per le PMI italiane, il tempo speso a recuperare versioni è denaro perso. Noi lo vediamo quando arrivano siti con plugin aggiornati a caso e nessun log delle modifiche. Git non serve solo ai developer di startup: serve a chiunque tocchi codice, anche se fai solo template WordPress.

Primo passo: inizializzare un repository con git init

Un repository (repo) è la cartella dove Git tiene traccia di tutto. git init crea una sottocartella nascosta .git dentro la tua directory. Da quel momento, ogni file che modifichi può essere tracciato.

Come si fa

cd /var/www/mio-sito
git init

# Output: Initialized empty Git repository in /var/www/mio-sito/.git/

Fatto. Ora puoi iniziare a salvare versioni. Consiglio pratico: fallo all'inizio del progetto, non dopo tre settimanne di lavoro — altrimenti perdi lo storico delle modifiche iniziali.

Aggiungere file all'area di staging con git add

Git non traccia automaticamente ogni file. Devi dirgli esplicitamente quali vuoi tenere d'occhio. git add sposta i file nell'area di staging, cioè la «lista delle cose da salvare nel prossimo snapshot».

Uso base

# Aggiungi un file specifico
git add index.html

# Aggiungi tutti i file della cartella corrente
git add .

# Aggiungi tutto, compresi quelli cancellati
git add -A

La differenza tra . e -A? git add . aggiunge i file nuovi e modificati nella directory corrente e sottodirectory. git add -A include anche le cancellazioni di file che hai rimosso. Per iniziare, usa sempre git add -A — eviti di lasciare file orfani.

Errore comune: dimenticare di aggiungere file prima del commit. Controlla sempre con git status.

git status
# On branch master
# Changes not staged for commit:
#   modified:   style.css
# Untracked files:
#   nuovo-script.js

Fissare uno snapshot con git commit

Il commit è la fotografia del tuo progetto in un istante. Ogni commit ha un messaggio che descrive cosa hai fatto. Non è una nota per te solo — è la storia del progetto che chiunque (tu futuro, colleghi, clienti) può leggere.

Come fare un buon commit

# Dopo aver fatto git add, esegui
git commit -m "Aggiunto form contatto con validazione lato client"

Regola d'oro: un commit = una modifica logica. Non mischiare la correzione di un bug con l'aggiunta di una nuova funzionalità. Messaggi chiari in italiano (o inglese, ma consistenti). Esempi:

• "Risolto errore 404 su pagina prodotto"
• "Aggiornato CSS del footer per mobile"
• "Rimosso codice morto in functions.php"

Per vedere la cronologia: git log --oneline (compatta) o git log (dettagliata).

Salvare su un server remoto con git push

Finora tutto è locale. Per collaborare o avere un backup fuori dal tuo computer, serve un repository remoto (GitHub, GitLab, Bitbucket, o un tuo server). Noi consigliamo GitHub perché è il più diffuso e ha piani gratuiti generosi. Ma anche un VPS con Git bare basta.

Collegare un remoto

# Aggiungi un repository remoto chiamato origin
git remote add origin https://github.com/tuo-utente/mio-sito.git

# Verifica
git remote -v

# Ora invia i commit locali al remoto
git push -u origin master

L'opzione -u imposta il ramo corrente (master) per seguire il remoto. Dopo, basta git push senza specificare ogni volta.

Attenzione: se stai usando il ramo principale chiamato main (sempre più comune), sostituisci master con main. GitHub di default crea un ramo main.

Scaricare le modifiche dal remoto con git pull

Quando lavori in team (o da due computer diversi), devi aggiornare la tua copia locale con le modifiche altrui. git pull fa due cose: scarica i nuovi commit (git fetch) e li fonde nel tuo ramo corrente (git merge).

# Assicurati di essere sul ramo corretto
git checkout master

# Recupera e fonde
git pull origin master

Se ci sono conflitti (tu e un collega avete modificato la stessa riga), Git ti mostra i file in conflitto. Dovrai modificarli manualmente e poi fare un nuovo commit. È normale, non spaventarti. Noi lo gestiamo ogni giorno.

Il flusso di lavoro completo in 5 comandi

Ecco la sequenza che usiamo quotidianamente:

1. git pull — aggiorna locale con le novità del remoto.
2. Modifichi i file.
3. git add -A — prepari tutto.
4. git commit -m "messaggio" — fermi lo snapshot.
5. git push — condividi con il team.

Con questi cinque passi non perdi più una modifica. E non hai più bisogno di cartelle finale_v2.

Esempio concreto: un sito HTML statico

Mettiamo in pratica. Creiamo un mini sito, lo versioniamo e lo carichiamo su GitHub.

mkdir mio-primo-sito
cd mio-primo-sito
git init
echo "<h1>Ciao Mondo</h1>" > index.html
git add index.html
git commit -m "Primo commit: pagina iniziale"

# Ora su GitHub crea un nuovo repository (senza README)
git remote add origin https://github.com/tuo-user/mio-primo-sito.git
git push -u origin master

# Modifichi index.html
echo "<h1>Benvenuto su Meteora Web</h1>" > index.html
git add -A
git commit -m "Aggiornato titolo con brand"
git push

Fatto. Ora hai il sito su GitHub, con storico completo. Puoi clonarlo su un altro computer con git clone https://github.com/tuo-user/mio-primo-sito.git.

Errori comuni e come evitarli

• Commit troppo grandi: se modifichi tutto in una volta, il messaggio diventa vago e perdere traccia è difficile. Spezza in commit atomici.
• Dimenticare il .gitignore: file come wp-config.php o node_modules/ non vanno in repository. Crea un file .gitignore subito dopo git init.
• Push su branch sbagliato: prima di fare push, controlla con git branch su quale ramo sei.
• Non fare pull prima di push: se qualcuno ha già spinto modifiche, riceverai un errore. Fai sempre git pull prima di git push.

Strumenti utili per principianti

La riga di comando è potente, ma all'inizio può essere ostica. Usa un client grafico come GitHub Desktop (semplicissimo) o VS Code con l'estensione Git integrata. Noi usiamo la shell per controllo totale, ma per un cliente che inizia suggeriamo GitHub Desktop. L'importante è capire i concetti.

Riferimento veloce dei comandi

Comando	Cosa fa
git init	Crea un nuovo repository locale
git add file	Aggiunge file all'area di staging
git commit -m "msg"	Salva uno snapshot con messaggio
git push	Invia commit al remoto
git pull	Scarica e fonde modifiche dal remoto
git status	Mostra lo stato del working directory
git log	Mostra cronologia commit

In sintesi — cosa fare adesso

1. Crea un nuovo progetto (o prendi una cartella esistente) ed esegui git init.
2. Aggiungi un file con git add -A e poi fai il tuo primo commit.
3. Crea un account GitHub (se non lo hai) e un nuovo repository vuoto. Poi collega il remoto con git remote add origin ....
4. Fai push dei tuoi commit su GitHub.
5. Modifica qualcosa e ripeti: add, commit, push.

Non serve sapere tutto subito. Parti da questi cinque comandi e il resto verrà da sé. Se lavori con WordPress e vuoi vedere come integrare Git in un flusso di sviluppo reale, qui abbiamo una guida SQL che mostra come teniamo traccia delle modifiche ai dati. Stessa filosofia: controllo e tracciabilità.