Git Hooks Pre-commit e Pre-push per Automatizzare la Qualità del Codice • Meteora Web Agency

Hai mai fatto un push dimenticando di eseguire i test locali? O mergeato codice che non passava il lint? Succede a tutti. Ma con i git hooks puoi automatizzare questi controlli prima che il danno arrivi sul repository remoto. Noi, di Meteora Web, usiamo i git hooks su ogni progetto serio da anni. Non per moda, ma perché la qualità del codice non si improvvisa: si automatizza.

Cosa sono i git hooks e come automatizzare la qualità del codice?

I git hooks sono script che git esegue automaticamente quando si verificano determinati eventi: commit, push, merge, rebase, etc. Sono file eseguibili (bash, Python, PHP, Node.js, quel che vuoi) dentro la cartella .git/hooks del tuo repository. Nomi come pre-commit, pre-push, post-commit, pre-rebase. L’idea è semplice: bloccare o modificare un’operazione se non soddisfa certi criteri. Automatizzare la qualità del codice con i git hooks significa intercettare errori prima che diventino problemi su branch condivisi. Non serve un tool esterno: solo uno script ben fatto.

Dove trovarli e come attivarli

In ogni repository c’è già una cartella .git/hooks con esempi (terminano in .sample). Basta rimuovere il suffisso e renderlo eseguibile:

cd .git/hooks
mv pre-commit.sample pre-commit
chmod +x pre-commit

Il problema è che .git non viene versionato: se cloni il repo, gli hooks non ci sono. La soluzione? Mettere gli hooks in una cartella versionata (es. .githooks) e configurare git per usarli:

git config core.hooksPath .githooks

Questo comando va eseguito una volta per repo (o in un setup script). In questo modo tutto il team condivide gli stessi controlli.

Come configurare un pre-commit hook per linting automatico?

Il pre-commit si attiva subito prima che git crei il commit. Se lo script restituisce un codice di uscita diverso da zero, il commit viene annullato. Ecco il caso classico: prima di fare il commit, eseguiamo un linter sul codice interessato. Esempio per un progetto PHP con PHP_CodeSniffer:

#!/bin/sh
# file .githooks/pre-commit

echo "Esecuzione PHPCS sui file modificati..."

# Recupera i file staged (solo .php)
staged=$(git diff --cached --name-only --diff-filter=ACM | grep '\.php$')
if [ -z "$staged" ]; then
    echo "Nessun file PHP modificato. Salto controllo."
    exit 0
fi

# Lancia phpcs su tutti i file staged
vendor/bin/phpcs --standard=PSR12 $staged

if [ $? -ne 0 ]; then
    echo "ERRORE: ci sono violazioni di coding standard. Correggi prima di committare."
    exit 1
fi

echo "PHPCS superato."

Salva il file come .githooks/pre-commit e rendilo eseguibile. La prossima volta che fai git commit, se c’è codice PHP non conforme allo standard PSR12, il commit viene interrotto. Niente più merge di codice mal formattato. Per progetti JavaScript, basta sostituire con eslint: npx eslint $staged.

Come usare pre-push per test e validazioni prima del push?

Il pre-push si attiva dopo il commit ma prima che i dati vengano inviati al remote. È il momento ideale per eseguire test più pesanti: unit test, test di integrazione, analisi statiche. Esempio con PHPUnit:

#!/bin/sh
# file .githooks/pre-push

echo "Esecuzione test prima del push..."

# Esegui la suite di test
vendor/bin/phpunit --configuration phpunit.xml

if [ $? -ne 0 ]; then
    echo "ERRORE: i test falliscono. Correggi prima di pushare."
    exit 1
fi

echo "Test superati. Push autorizzato."

Attenzione: i test possono essere lenti. Noi consigliamo di limitare il pre-push ai test essenziali (un minuto massimo). Se hai una suite lunga, usa un flag per saltare lo skip (es. git push --no-verify) ma solo in casi eccezionali.

Gestire gli skip con responsabilità

Git permette di bypassare gli hooks con --no-verify per commit e push. Noi lo usiamo solo per emergenze (fix urgenti su produzione). Il resto del tempo, gli hooks sono obbligatori. Per evitare abusi, puoi aggiungere un log che registri chi ha saltato il controllo, oppure integrare un CI che verifica lo stesso.

Strumenti per gestire git hooks in team: Husky, Lefthook e script custom

Quando lavoriamo con team JavaScript, spesso usiamo Husky: un pacchetto npm che semplifica la configurazione degli hooks. Basta installarlo e definire gli script in package.json:

npx husky-init && npm install

Poi aggiungi un hook: npx husky add .husky/pre-commit "npx lint-staged". Ma attenzione: Husky crea la cartella .husky che va versionata. Funziona bene, ma ti vincola a Node.js. Lefthook è un'alternativa multipiattaforma (Go) che legge una configurazione YAML. Noi preferiamo script bash semplici per progetti PHP, perché non vogliamo dipendenze extra. La regola è: scegli lo strumento che il tuo team capisce e mantiene.

Errori comuni da evitare con i git hooks

Il più frequente? Hook troppo lento o troppo severo. Un pre-commit che esegue l’intera suite di test (5 minuti) manderà il team su tutte le furie. Meglio un lint veloce (millisecondi) e test solo nel pre-push. Secondo errore: dimenticare di rendere eseguibili gli script su macOS/Linux (chmod +x). Terzo: non testare lo script su più ambienti (Windows con Git Bash ha bisogno di attenzione). Quarto: non versionare gli hooks -> ogni sviluppatore deve configurarli a mano.

Una checklist per iniziare subito

Identifica i controlli essenziali: lint, unit test, security scan, analisi statica.
Crea la cartella .githooks e sposta gli script.
Configura core.hooksPath nel .gitconfig locale o in un setup script.
Testa con un commit fittizio per verificare che il blocco funzioni.
Documenta nel README come attivare gli hooks per i nuovi sviluppatori.

Cosa fare adesso

Non aspettare il prossimo merge disastroso. Implementa subito un pre-commit hook per il tuo linguaggio. Se lavori con PHP, copia lo script sopra. Per JavaScript, usa npx lint-staged. Per Python, flake8 o black. Il tempo investito oggi si ripaga dieci volte in ore di debug evitate. Noi, di Meteora Web, lo facciamo su ogni progetto che sviluppiamo – nella nostra pillar guide su Git trovi tutto il workflow di team. Buon hooking!