Automatizza il tuo Flusso di Lavoro: Una Guida Pratica agli Hook Lato Client di Git

Gli hook di Git sono strumenti potenti, ma spesso sottoutilizzati, all'interno dell'ecosistema Git. Permettono agli sviluppatori di attivare automaticamente script personalizzati in punti specifici del flusso di lavoro di sviluppo—prima o dopo eventi come il commit, il push o il merge. Per i singoli sviluppatori che lavorano su un repository locale, gli hook lato client sono essenziali per far rispettare la qualità del codice, eseguire test locali e standardizzare i controlli pre-invio senza fare affidamento sull'applicazione centralizzata lato server.

Questa guida esplorerà i meccanismi degli hook lato client di Git, concentrandosi sui tipi più comuni e utili: pre-commit e post-merge. Padroneggiando questi hook, potrai automatizzare le attività ripetitive, individuare gli errori precocemente e migliorare significativamente la coerenza e l'affidabilità nel tuo processo di sviluppo quotidiano.

Comprendere gli Hook di Git

Gli hook di Git sono script eseguibili che Git esegue automaticamente prima o dopo determinate operazioni principali. Risiedono nella directory .git/hooks di ogni repository Git. Git include degli hook di esempio (che di solito terminano con .sample), ma diventano attivi solo quando li si rinomina rimuovendo l'estensione .sample.

Hook Lato Client vs. Hook Lato Server

È fondamentale distinguere tra i due tipi principali:

• Hook Lato Client: Vengono eseguiti sulla macchina locale dello sviluppatore (ad esempio, pre-commit, commit-msg). Sono eccellenti per la validazione locale e per migliorare l'esperienza utente.
• Hook Lato Server: Vengono eseguiti sul server centrale quando viene ricevuto un push (ad esempio, pre-receive, post-receive). Questi sono tipicamente utilizzati per le politiche di applicazione a livello di progetto.

Nota Importante: Poiché gli hook lato client sono locali, non vengono automaticamente clonati o condivisi quando si clona un repository. Qualsiasi configurazione deve essere eseguita manualmente da ogni sviluppatore, o gestita tramite script di inizializzazione.

Localizzare e Abilitare gli Hook Lato Client

Tutti gli hook lato client risiedono nella directory .git/hooks all'interno del tuo repository.

Quando inizializzi un nuovo repository, Git fornisce dei modelli:

git init
# Questo crea una directory .git/hooks popolata con file di esempio come pre-commit.sample

Per abilitare un hook, è sufficiente rinominare il file di esempio. Ad esempio, per abilitare l'hook pre-commit:

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

Gli script qui posizionati devono essere eseguibili (da cui il chmod +x). Generalmente vengono eseguiti come script di shell, ma possono essere scritti in qualsiasi linguaggio, purché sia presente la linea shebang (#!/bin/bash, #!/usr/bin/env python, ecc.) e l'interprete sia disponibile.

Esempio Pratico 1: L'Hook pre-commit

L'hook pre-commit viene eseguito appena prima che Git richieda un messaggio di commit. È il luogo ideale per eseguire controlli sul codice che sta per essere committato.

Casi d'Uso Comuni per pre-commit:

1. Linting/Controllo dello Stile: Assicurarsi che il codice aderisca alle guide di stile stabilite (es. ESLint, Black).
2. Esecuzione di Test Unitari: Eseguire test veloci e critici.
3. Controllo della Sintassi: Verificare la correttezza sintattica di base.
4. Prevenzione di Commit Accidentali: Assicurarsi che non rimangano chiavi segrete o istruzioni di debug.

Creare un Semplice Hook pre-commit (Esempio Shell)

Questo script di esempio verifica se un file in staging per il commit contiene la parola TODO: e, se trovata, fa fallire il commit, costringendo lo sviluppatore a risolvere quei segnaposto.

Crea il file .git/hooks/pre-commit e aggiungi il seguente contenuto:

#!/bin/bash

# 1. Controlla i file in staging per 'TODO:'
STAGED_FILES=$(git diff --cached --name-only)

if grep -q "TODO:" <<< "$STAGED_FILES"; then
    echo "\n[HOOK FAILED] Trovati marcatori 'TODO:' nei file in staging. Risolvi questi prima di fare il commit."
    # Stampa i file specifici contenenti i marcatori (opzionale)
    git diff --cached | grep "TODO:"
    exit 1 # Esci con stato diverso da zero per annullare il commit
fi

# 2. Esegui un controllo sintattico di base sui file Python (richiede 'python -m py_compile')
for FILE in $(git diff --cached --name-only --diff-filter=ACM | grep '\.py$'); do
    echo "Controllo della sintassi per $FILE..."
    python -m py_compile "$FILE" > /dev/null 2>&1
    if [ $? -ne 0 ]; then
        echo "[HOOK FAILED] Errore di sintassi trovato in $FILE."
        exit 1
    fi
done

# Se tutti i controlli passano
echo "Controlli pre-commit superati con successo."
exit 0 # Esci con stato zero per permettere il commit

Se lo script termina con uno stato diverso da zero (come exit 1), Git abortisce immediatamente il processo di commit e stampa il messaggio di errore.

Buona Prassi: Per linting e formattazione complessi, considera l'utilizzo di strumenti esterni per la gestione degli hook come Husky (per gli ecosistemi JavaScript) o Pre-commit (uno strumento indipendente dal framework) che gestiscono automaticamente l'installazione degli hook, la condivisione e la gestione delle dipendenze.

Esempio Pratico 2: L'Hook post-merge

L'hook post-merge viene eseguito immediatamente dopo il completamento di un'operazione git merge riuscita. Questo hook è utile per eseguire pulizie o aggiornare le dipendenze locali in base al codice appena unito.

Casi d'Uso Comuni per post-merge:

1. Aggiornamento dei Submoduli: Aggiornare automaticamente i repository dipendenti.
2. Ricostruzione delle Dipendenze: Eseguire npm install o equivalente se i file delle dipendenze (package.json, requirements.txt) sono stati modificati.
3. Notifica agli Utenti: Visualizzare informazioni rilevanti sul branch.

Creare un Semplice Hook post-merge (Aggiornamento Dipendenze)

Se il tuo progetto utilizza Node.js, potresti voler assicurarti che node_modules sia aggiornato dopo aver unito un branch che ha modificato package.json o package-lock.json.

Crea il file .git/hooks/post-merge:

#!/bin/bash

echo "Hook post-merge attivato."

# Controlla se package.json o package-lock.json sono stati modificati nel merge
if git diff --name-only HEAD@{1} HEAD | grep -Eq "(package\.json|package-lock\.json)"; then
    echo "File delle dipendenze modificati. Eseguo npm install..."
    npm install
    if [ $? -eq 0 ]; then
        echo "Dipendenze aggiornate con successo."
    else
        echo "ATTENZIONE: npm install non riuscito dopo il merge. Esegui 'npm install' manualmente."
    fi
else
    echo "File delle dipendenze invariati. Salto npm install."
fi

exit 0

Questo hook sfrutta le capacità di ref-log di Git (HEAD@{1} si riferisce allo stato prima del merge) per confrontare i file, rendendo l'azione condizionale ed evitando esecuzioni non necessarie.

Altri Hook Lato Client Utili

Mentre pre-commit e post-merge sono molto utilizzati, diversi altri hook lato client possono ottimizzare il tuo flusso di lavoro:

• commit-msg: Viene eseguito dopo che l'utente inserisce il messaggio di commit, ma prima che il commit sia finalizzato. Utile per imporre standard sui messaggi di commit (es. formato Conventional Commits).
• pre-rebase: Viene eseguito prima che inizi un rebase. Può verificare se certi branch devono essere protetti dal rebase.
• post-checkout: Viene eseguito dopo che un git checkout ha avuto successo. Utile per cambiare variabili d'ambiente o configurazioni degli strumenti in base al branch selezionato.

Nome Hook	Punto di Attivazione	Caso d'Uso Principale
pre-commit	Prima della creazione del commit	Linting del codice, test locali, formattazione
commit-msg	Dopo l'inserimento del messaggio	Applicazione del formato del messaggio (es. ticket JIRA)
post-merge	Dopo un merge riuscito	Aggiornamento dei submoduli, aggiornamento delle dipendenze
post-checkout	Dopo un checkout riuscito	Cambiare le configurazioni dell'ambiente

Riepilogo e Prossimi Passi

Gli hook lato client di Git offrono un modo a costo zero per automatizzare attività ripetitive e imporre standard di qualità locali direttamente nel tuo ambiente di sviluppo. Servono come una cruciale prima linea di difesa contro commit sciatto e problemi di integrazione.

Per usarli efficacemente:

1. Identifica le Attività Ripetitive: Determina i controlli che esegui manualmente prima di fare il commit o il merge.
2. Localizza .git/hooks: Naviga in questa directory nel tuo progetto.
3. Abilita e Scrivi lo Script: Copia il file .sample, rinominalo, assicurati che sia eseguibile (chmod +x) e scrivi la tua logica di automazione.
4. Considera Strumenti di Gestione: Per i team, indaga strumenti come pre-commit per sincronizzare le installazioni degli hook tra gli sviluppatori.