Hook Git

Gli hook devono essere eseguibili, quindi potrebbe essere necessario modificare le autorizzazioni file dello script se lo stai creando da zero. Ad esempio, per assicurarti che prepare-commit-msg sia eseguibile, esegui il seguente comando:

Ora dovresti vedere questo messaggio al posto del messaggio di commit predefinito ogni volta che esegui git commit. Ne esamineremo più in dettaglio il funzionamento nella sezione Preparazione del messaggio di commit. Per il momento, vedremo come personalizzare alcune delle funzionalità interne di Git.

Gli script di esempio integrati sono riferimenti molto utili, in quanto documentano i parametri che vengono passati a ciascun hook (variano da hook a hook).

Gli script integrati sono principalmente script di shell e PERL, ma puoi utilizzare il linguaggio di scripting che preferisci a condizione che sia eseguibile. La riga shebang (#! /bin/sh) presente in ogni script definisce in che modo deve essere interpretato il file. Quindi, per utilizzare un linguaggio diverso, devo solo cambiarlo seguendo il percorso dell'interprete.

Ad esempio, possiamo scrivere uno script Python eseguibile nel file prepare-commit-msg invece di utilizzare i comandi della shell. L'hook riportato di seguito eseguirà la stessa azione dello script della shell di cui alla sezione precedente.

Come puoi notare, la prima riga è cambiata in modo da puntare all'interprete Python. Inoltre, invece di utilizzare $1 per accedere al primo argomento passato allo script, abbiamo utilizzato sys.argv [1] (anche questo argomento verrà ripreso in seguito nell'articolo).

Si tratta di una funzionalità molto efficace per gli hook Git perché consente di lavorare in qualsiasi linguaggio.

Gli hook sono locali in qualsiasi repository Git e non vengono copiati nel nuovo repository quando esegui il comando git clone. Inoltre, poiché gli hook sono locali, possono essere modificati da chiunque abbia accesso al repository.

Questo ha un notevole impatto sulla configurazione degli hook per un team di sviluppatori. Innanzitutto, devi trovare un modo per assicurarti che i membri del team siano sempre informati. In secondo luogo, non puoi obbligare gli sviluppatori a creare commit con determinate caratteristiche; puoi solo invitarli a farlo.

Mantenere gli hook per un team di sviluppatori può essere un po' complicato perché la directory .git/hooks non è clonata con il resto del progetto, né viene controllata della versione. Una soluzione semplice per entrambi questi problemi è l'archiviazione degli hook nella directory effettiva del progetto (sopra la directory .git ). Questo ti consente di modificarli come qualsiasi altro file con versione controllata. Per installare l'hook, puoi creare un link simbolico ad esso in .git/hooks, oppure puoi semplicemente copiarlo e incollarlo nella directory .git/hooks ogni volta che l'hook viene aggiornato.

In alternativa, Git fornisce anche un meccanismo di directory dei modelli che semplifica l'installazione automatica degli hook. Tutti i file e le directory contenuti in questa directory dei modello vengono copiati nella directory .git ogni volta che utilizzi git init o git clone.

Tutti gli hook locali descritti di seguito possono essere modificati, o completamente disinstallati, dal responsabile di un repository. La scelta di utilizzare o meno un hook dipende interamente dai singoli membri del team. Tenendo conto di questo aspetto, è preferibile pensare agli hook Git come a un comodo strumento di sviluppo piuttosto che a una policy di sviluppo applicata in modo rigoroso.

Detto questo, è possibile rifiutare i commit non conformi ad alcuni standard utilizzando gli hook lato server. Ne parleremo più in dettaglio nel corso dell'articolo.

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• post-checkout
• pre-rebase

I primi quattro hook ti consentono di collegarti all'intero ciclo di vita del commit mentre con gli ultimi due hook puoi eseguire alcune azioni o controlli di sicurezza aggiuntivi rispettivamente per i comandi git checkout e git rebase.

Tutti i pre-hook consentono di modificare l'azione che sta per avvenire, mentre i post hook vengono utilizzati solo per le notifiche.

Vedremo anche alcune tecniche utili per analizzare gli argomenti dell'hook e richiedere informazioni sul repository utilizzando comandi Git di livello inferiore.

Lo script pre-commit viene eseguito ogni volta che esegui git commit prima che Git chieda allo sviluppatore un messaggio di commit o generi un oggetto di commit. Puoi utilizzare questo hook per ispezionare la snapshot di cui sta per essere eseguito il commit. Ad esempio, potresti voler eseguire alcuni test automatici per assicurarti che il commit non interrompa alcuna funzionalità esistente.

Non viene passato alcun argomento allo script pre-commit e l'uscita con uno stato diverso da zero annulla l'intero commit. Diamo un'occhiata a una versione semplificata (e più dettagliata) dell'hook pre-commit integrato. Questo script interrompe il commit se trova errori di spazio bianco, come definito dal comando git diff-index (gli spazi bianchi finali, le righe contenenti solo spazi bianchi e uno spazio seguito da una tabulazione all'interno del rientro iniziale di una riga sono considerati errori per impostazione predefinita).

Per utilizzare git diff-index, è necessario capire qua è il riferimento di commit con il quale stiamo confrontando l'indice. Di norma, è HEAD; tuttavia, HEAD non esiste quando si crea il commit iniziale, quindi come prima attività dobbiamo considerare questo caso limite. A tale scopo, utilizziamo git rev-parse --verify, che verifica semplicemente se l'argomento (HEAD) è un riferimento valido. La porzione >/dev/null 2>&1 annulla qualsiasi output di git rev-parse. HEAD o un oggetto di commit vuoto è memorizzato nella variabile against in modo da essere utilizzato con git diff-index. L'hash 4b825d... è un ID di commit magico che rappresenta un commit vuoto.

Il comando git diff-index --cached confronta un commit con l'indice. Passando l'opzione --check, chiediamo di inviare un avviso qualora le modifiche introducano errori negli spazi bianchi. In tal caso, interrompiamo il commit restituendo uno stato di uscita pari a 1; diversamente, effettuiamo l'uscita con 0 e il flusso di lavoro di commit continua normalmente.

Questo è solo un esempio di hook di pre-commit. Può capitare di utilizzare i comandi Git esistenti per eseguire test sulle modifiche introdotte dal commit proposto; tuttavia, è possibile effettuare tutte le azioni desiderate in pre-commit, inclusa l'esecuzione di altri script, l'esecuzione di una suite di test di terze parti o il controllo dello stile del codice con Lint.

L'hook prepare-commit-msg viene chiamato dopo l'hook pre-commit per compilare l'editor di testo con un messaggio di commit. È utile per modificare i messaggi di commit generati automaticamente per i commit sottoposti a squash o merge.

Allo script prepare-commit-msg vengono passati da uno o tre argomenti:

1. Il nome di un file temporaneo che contiene il messaggio. Puoi modificare il messaggio di commit modificando questo file sul posto.

2. Il tipo di commit. Può essere message (opzione -m o -F), template (opzione -t), merge (se il commit è di merge), o squash (se il esegue lo squash di altri commit).

3. L'hash SHA1 del commit pertinente. Fornito solo se è stata fornita l'opzione -c, -C o --amend.

Analogamente a pre-commit, l'uscita con uno stato diverso da 0 annulla il commit.

Abbiamo già visto un semplice esempio di modifica del messaggio di commit, ma diamo un'occhiata a uno script più utile. Quando si utilizza uno strumento di rilevamento dei problemi, si tende spesso a risolvere ogni problema in un branch separato. Se includi il numero del problema nel nome del branch, puoi scrivere un hook prepare-commit-msg per includerlo automaticamente in ogni messaggio di commit di quel branch.

Innanzitutto, il precedente hook prepare-commit-msg mostra come raccogliere tutti i parametri passati allo script. Quindi, chiama git symbolic-ref --short HEAD per ottenere il nome del branch che corrisponde a HEAD. Se il nome del branch inizia con issue-, riscrive il contenuto del file del messaggio di commit per includere il numero del problema nella prima riga. Quindi, se il nome del branch è issue-224, verrà generato il seguente messaggio di commit.

Un aspetto da ricordare quando si utilizza prepare-commit-msg è il fatto che funziona anche quando l'utente passa un messaggio con l'opzione -m di git commit. Ciò significa che lo script precedente inserirà automaticamente la stringa ISSUSE- [#] senza consentire all'utente di modificarla. Puoi gestire questo caso verificando se il secondo parametro (commit_type) è uguale a message.

Tuttavia, senza l'opzione -m, l'hook prepare-commit-msg consente all'utente di modificare il messaggio dopo che è stato generato, quindi questo script rappresenta più una comodità per l'utente che un modo per applicare una policy dei messaggi di commit. Per quest'ultima funzione, è necessario l'hook commit-msg che verrà descritto nella prossima sezione.

L'hook commit-msg è molto simile all'hook prepare-commit-msg, ma viene chiamato dopo che l'utente immette un messaggio di commit. È utile per avvertire gli sviluppatori che il loro messaggio non è conforme agli standard del tuo team.

L'unico argomento passato a questo hook è il nome del file che contiene il messaggio. Se l'utente inserisce un messaggio non conforme agli standard, può modificare questo file sul posto (analogamente a prepare-commit-msg) oppure può annullare completamente il commit effettuando l'uscita con uno stato diverso da 0.

Ad esempio, il seguente script verifica che l'utente non abbia eliminato la stringa ISSUE- [#] generata automaticamente dall'hook prepare-commit-msg nella sezione precedente.

Sebbene questo script venga chiamato ogni volta che l'utente crea un commit, ti consigliamo di evitare di effettuare altre operazioni oltre al controllo del messaggio di commit. Se devi informare altri servizi dell'avvenuto salvataggio di una snapshot, dovresti utilizzare l'hook post-commit.

L'hook post-commit viene chiamato immediatamente dopo l'hook commit-msg. Non può modificare il risultato dell'operazione git commit, quindi è utilizzato principalmente per finalità di notifica.

Lo script non accetta parametri e il suo stato di uscita non influisce in alcun modo sul commit. Per la maggior parte degli script post-commit, avrai la necessità di accedere al commit appena creato. Puoi utilizzare git rev-parse HEAD per ottenere l'hash SHA1 del nuovo commit oppure utilizzare git log -1 HEAD per ottenere tutte le relative informazioni.

Ad esempio, se desideri inviare un'e-mail al tuo responsabile ogni volta che esegui il commit di una snapshot (probabilmente non è la migliore idea per la maggior parte dei flussi di lavoro), puoi aggiungere il seguente hook post-commit.

È possibile utilizzare post-commit per attivare un sistema di continuous integration locale, ma il più delle volte è preferibile farlo nell'hook post-receive. Viene eseguito sul server anziché sul computer locale dell'utente e viene eseguito anche ogni volta che uno sviluppatore effettua il push del proprio codice. Pertanto, è molto più indicato per eseguire la continuous integration.

L'hook post-checkout funziona in modo molto simile all'hook post-commit, ma viene chiamato ogni volta che esegui il checkout di un riferimento con git checkout. È utile per eliminare dalla directory di lavoro i file generati che potrebbero creare confusione.

L'hook accetta tre parametri e il suo stato di uscita non ha alcun effetto sul comando git checkout.

1. Il riferimento dell'HEAD precedente

2. Il riferimento del nuovo HEAD

3. Un flag che indica se si trattava di un checkout di branch o di un checkout di file. Il flag sarà rispettivamente 1 e 0.

Un problema comune che interessa gli sviluppatori Python è quello che si verifica quando i file .pyc permangono dopo aver cambiato branch. L'interprete a volte utilizza questi file .pyc invece del file di origine .py . Per evitare confusione, puoi eliminare tutti i file .pyc ogni volta che effettui il checkout di un nuovo branch utilizzando il seguente script post-checkout:

L'attuale directory di lavoro per gli script di hook è sempre impostata sulla radice del repository, quindi la chiamata os.walk('.') viene iterata su tutti i file del repository. Successivamente, controlliamo la sua estensione e, se si tratta di un file .pyc, lo eliminiamo.

Puoi anche utilizzare l'hook post-checkout per modificare la directory di lavoro in base al branch di cui hai eseguito il checkout. Ad esempio, potresti utilizzare un branch plugin per archiviare tutti i tuoi plug-in al di fuori della base di codice principale. Se questi plug-in richiedono molti file binari che altri branch non hanno, puoi crearli in modo selettivo solo quando ti trovi nel branch plug-in.

L'hook pre-rebase viene chiamato prima che git rebase effettui modifiche, pertanto è utile per assicurarsi che non succeda nulla di irreparabile.

Questo hook richiede due parametri: il branch upstream da cui è stato effettuato il fork della serie e il branch per il quale viene effettuato il rebasing. Il secondo parametro è vuoto quando si effettua il rebasing del branch corrente. Per annullare il rebasing, effettua l'uscita con uno stato diverso da zero.

Ad esempio, se vuoi impedire completamente il rebasing nel repository, puoi utilizzare il seguente script pre-rebase:

Ora, ogni volta che esegui git rebase, verrà visualizzato questo messaggio:

Per un esempio più approfondito, dai un'occhiata allo script pre-rebase.sample incluso, che è più efficace nell'individuare le situazioni in cui non consentire il rebasing. Verifica se il branch dell'argomento di cui stai cercando di effettuare il rebasing è già stato sottoposto a merge nel branch nect (che si presume sia il branch mainline). In tal caso, il rebasing creerebbe dei problemi, quindi lo script lo interrompe.

• pre-receive
• Aggiorna
• post-receive

Tutti questi hook ti consentono di reagire alle diverse fasi del processo git push.

L'output degli hook lato server viene reindirizzato alla console del client, quindi è molto facile reinviare i messaggi allo sviluppatore. Tuttavia, dovresti anche tenere presente che questi script non restituiscono il controllo del terminale finché non terminano l'esecuzione, quindi fai attenzione a non eseguire operazioni a esecuzione prolungata.

L'hook pre-receive viene eseguito ogni volta che qualcuno utilizza git push per eseguire il push dei commit al repository. Dovrebbe sempre risiedere nel repository remote che è la destinazione del push, non nel repository di origine.

L'hook viene eseguito prima che qualsiasi riferimento venga aggiornato, quindi è utile per applicare qualsiasi tipo di policy di sviluppo desiderata. Se hai dei dubbi su chi sta eseguendo il push, sul modo in cui il messaggio di commit è formattato o sulle modifiche contenute nel commit, puoi semplicemente rifiutare il commit. Anche se non puoi impedire agli sviluppatori di creare commit non validi, puoi evitare che tali commit entrino nella base di codice ufficiale rifiutandoli con pre-receive.

Lo script non accetta parametri, ma ogni riferimento sottoposto a push viene passato allo script su una riga separata di input standard nel seguente formato:

Puoi vedere come funziona questo hook utilizzando uno script pre-receive molto semplice che legge semplicemente i riferimenti sottoposti a push e li stampa.

Anche questo hook è leggermente diverso dagli altri perché le informazioni vengono passate allo script tramite input standard invece che come argomenti della riga di comando. Dopo aver inserito lo script precedente nella directory .git/hooks di un repository remoto e aver eseguito il push del branch main, nella console verrà visualizzato un risultato simile al seguente:

Puoi utilizzare questi hash SHA1, insieme ad alcuni comandi Git di livello inferiore, per ispezionare le modifiche che verranno introdotte. Ecco alcuni casi d'uso comuni:

• Rifiutare le modifiche che coinvolgono un rebasing upstream.
• Impedire merge senza avanzamento rapido.
• Verificare che l'utente disponga delle autorizzazioni appropriate per apportare le modifiche previste (utilizzato principalmente per flussi di lavoro Git centralizzati).

Se viene effettuato il push di più riferimenti, la restituzione di uno stato diverso da zero da pre-receive li interrompe tutti. Se vuoi accettare o rifiutare i branch caso per caso, devi utilizzare invece l'hook update.

L'hook update viene chiamato dopo pre-receive e funziona più o meno allo stesso modo. Viene chiamato prima ancora che sia applicato un aggiornamento, ma viene chiamato separatamente per ogni riferimento di cui è stato effettuato il push. Ciò significa che se l'utente tenta di eseguire il push di 4 branch, update viene eseguito 4 volte. A differenza di pre-receive, non occorre che questo hook legga dati di input standard. Accetta invece i 3 argomenti seguenti:

1. Il nome del riferimento che viene aggiornato.

2. Il vecchio nome dell'oggetto memorizzato nel riferimento.

3. Il nuovo nome dell'oggetto memorizzato nel riferimento.

Si tratta delle stesse informazioni passate a pre-receive, ma poiché update viene chiamato separatamente per ogni riferimento, puoi rifiutare alcuni riferimenti e consentirne altri.

L'hook update riportato sopra riporta semplicemente il branch e gli hash di commit vecchi/nuovi. Quando esegui il push di più branch al repository remoto, verrà visualizzata l'istruzione print eseguita per ogni branch.

L'hook post-receive viene chiamato dopo un'operazione push riuscita, pertanto è utile per l'esecuzione di notifiche. Per molti flussi di lavoro, è maggiormente utile per attivare le notifiche rispetto a post-commit perché le modifiche sono disponibili su un server pubblico invece di risiedere solo sul computer locale dell'utente. L'invio di e-mail ad altri sviluppatori e l'attivazione di un sistema di continuous integration sono casi d'uso comuni per post-receive.

Lo script non accetta parametri, ma riceve le stesse informazioni di pre-receive tramite input standard.

In questo articolo, abbiamo imparato a utilizzare gli hook Git per modificare il comportamento interno e per ricevere notifiche quando si verificano determinati eventi in un repository. Gli hook sono script ordinari che risiedono nel repository .git/hooks, pertanto sono molto facili da installare e personalizzare.

Abbiamo anche esaminato alcuni degli hook locali e lato server più comuni, che ci consentono di collegarci all'intero ciclo di vita di sviluppo. Ora sappiamo come eseguire azioni personalizzabili in ogni fase del processo di creazione del commit, così come nel processo git push. Con un po' di conoscenza dello scripting, potrai effettuare praticamente qualsiasi operazione utilizzando un repository Git.