Git per pubblicare il tuo sito

Se modifichi il codice del tuo sito, prima o poi ti capita di sovrascrivere il file sbagliato via FTP, o di non ricordare più cosa avevi cambiato e quando. Git risolve entrambi i problemi: tiene la storia di ogni modifica e ti permette di pubblicare sul server solo ciò che hai deciso, con un comando. In questa guida vediamo due modi pratici per usarlo con il tuo hosting.

Git in due parole

Git è un sistema di controllo di versione. Ogni volta che salvi un insieme di modifiche crei un commit: una fotografia del progetto con un messaggio che spiega cosa hai fatto. Puoi tornare a qualunque fotografia precedente, confrontare versioni, lavorare su più rami in parallelo.

I comandi che userai più spesso sono pochi:

git status                  # cosa è cambiato
git add file.php            # prepara un file per il commit
git add .                   # prepara tutte le modifiche
git commit -m "Nuovo footer"
git log --oneline           # storia dei commit
git push                    # invia i commit a un repository remoto
git pull                    # scarica e applica i commit dal remoto

Cosa ti serve

• Git sul tuo computer: su macOS e Linux spesso è già presente (prova git --version), su Windows si installa con Git for Windows.
• Accesso SSH al tuo hosting: da noi è disponibile sulla porta 7530, con il nome utente del tuo account e l’indirizzo del server indicato nell’email di attivazione. Ti consigliamo di usare una chiave: vedi Usare la chiave SSH sul tuo hosting.
• Git sul server: una volta collegato verifica con git --version. Se non risulta disponibile, faccelo sapere con un ticket.

Per comodità, nel file ~/.ssh/config del tuo computer definisci un nome breve per il server, così Git non ha bisogno di sapere porta e utente:

Host miosito
  HostName server
  Port 7530
  User tuoutente
  IdentityFile ~/.ssh/id_ed25519

Cosa mettere (e cosa no) nel repository

Prima di iniziare, decidi cosa versionare. Nel repository va il codice che scrivi tu; restano fuori:

• file con password e configurazioni del server (per WordPress: wp-config.php; per altri progetti: .env);
• file caricati dagli utenti (per WordPress: wp-content/uploads);
• cartelle di cache e file temporanei;
• dipendenze scaricabili (come vendor/ o node_modules/), se le ricostruisci con un comando.

Si elencano nel file .gitignore. Un esempio per un tema WordPress personalizzato è semplicissimo: versioni solo la cartella del tema. Un esempio più generale:

wp-config.php
.env
wp-content/uploads/
wp-content/cache/
node_modules/
*.log
*.sql

Il database non si gestisce con Git: contenuti, ordini e utenti vivono lì e cambiano di continuo. Git serve per il codice.

Metodo 1: il server scarica da un repository

È il metodo più semplice se usi già un servizio di hosting del codice (GitHub, GitLab, Bitbucket o simili). Il flusso è:

1. lavori sul tuo computer e fai git push verso il servizio;
2. ti colleghi al server e fai git pull nella cartella del sito.

La prima volta, sul server:

ssh miosito
cd ~/domains/tuodominio.it/public_html/wp-content/themes
git clone git@servizio-git:tuonome/mio-tema.git

Per i repository privati il server deve potersi autenticare presso il servizio Git. Il modo pulito è una deploy key: una chiave SSH generata sul server, con accesso in sola lettura a quel solo repository. La generi sul server con ssh-keygen e ne aggiungi la parte pubblica nelle impostazioni del repository. Così non porti mai la tua chiave personale sul server.

Gli aggiornamenti successivi:

ssh miosito
cd ~/domains/tuodominio.it/public_html/wp-content/themes/mio-tema
git pull

Metodo 2: push diretto al tuo hosting

Se non vuoi usare servizi esterni, puoi fare del server stesso il «remoto» a cui spingi le modifiche. Si crea un repository bare (senza file di lavoro) fuori dal sito e un piccolo script che, a ogni push, copia la versione aggiornata nella cartella pubblica.

Sul server

mkdir -p ~/repo/sito.git
cd ~/repo/sito.git
git init --bare

Poi crea lo script hooks/post-receive:

nano ~/repo/sito.git/hooks/post-receive

con questo contenuto (adatta il percorso e il nome del ramo):

#!/bin/sh
TARGET="$HOME/domains/tuodominio.it/public_html/wp-content/themes/mio-tema"
mkdir -p "$TARGET"
git --work-tree="$TARGET" --git-dir="$HOME/repo/sito.git" checkout -f main

E rendilo eseguibile:

chmod +x ~/repo/sito.git/hooks/post-receive

Sul tuo computer

cd mio-tema
git remote add produzione miosito:repo/sito.git
git push produzione main

Da quel momento, ogni git push produzione main aggiorna il sito. Il repository sta in ~/repo, quindi la cartella .git non finisce mai dentro public_html.

Attenzione: checkout -f sovrascrive i file che Git conosce. Se qualcuno modifica quei file direttamente sul server (via FTP o dall’editor di WordPress), al push successivo quelle modifiche si perdono. La regola d’oro è: i file versionati si cambiano solo attraverso Git.

Proteggere la cartella .git

Con il metodo 1 il clone si trova dentro public_html, e con lui la cartella nascosta .git, che contiene tutta la storia del codice. Assicurati che non sia raggiungibile dal web. Sui server che leggono .htaccess puoi aggiungere, nella cartella principale del sito:

RedirectMatch 404 /\.git

Poi verifica dal browser che https://tuodominio.it/wp-content/themes/mio-tema/.git/config restituisca un errore e non il contenuto del file. Se hai dubbi sulla configurazione del tuo piano, chiedici conferma con un ticket.

Un flusso di lavoro tipico

1. Modifichi i file in locale e provi le modifiche.
2. git add . e git commit -m "Descrizione chiara".
3. git push (verso il servizio Git o direttamente verso il server).
4. Se usi il metodo 1, git pull sul server.
5. Svuoti la cache del sito, se ne usi una: per WordPress, per esempio, dal plugin iWebLab Cache. Se le modifiche riguardano CSS o JavaScript e non le vedi, il motivo è quasi sempre la cache.

Tornare indietro

Il bello di Git è che un errore non è mai definitivo. Se l’ultimo commit ha rotto qualcosa:

git revert HEAD          # crea un nuovo commit che annulla l'ultimo
git push produzione main

revert non cancella la storia: aggiunge un commit «al contrario». È il modo più sicuro per tornare indietro su un sito in produzione.

Quando Git non è la risposta

Git è perfetto per temi, plugin e applicazioni scritte da te. Non è adatto a gestire un intero WordPress con plugin di terzi che si aggiornano da soli, né a fare il backup di contenuti e database. Per quello ci sono i backup automatici, che puoi ripristinare in autonomia dal pannello, e per i plugin WP-CLI. Per caricare file una tantum, invece, guarda Copiare file con SCP e rsync.