Nozioni di base di Git Hooks: un’infarinatura<\/h2>\n
Una delle caratteristiche principali di Git<\/a> sono gli hook: un potente meccanismo che permette di automatizzare le attivit\u00e0, applicare gli standard e garantire flussi di lavoro coerenti durante il ciclo di vita di un progetto.<\/p>\n Gli hook di Git sono script che vengono eseguiti automaticamente in punti specifici del flusso di lavoro di Git. Potete usarli per personalizzare ed estendere il comportamento di Git in base alle esigenze del progetto. Gli hook garantiscono il mantenimento della qualit\u00e0 del codice, l’esecuzione dei test e l’organizzazione delle distribuzioni senza problemi.<\/p>\n Git offre diversi tipi di hook, ognuno dei quali si attiva in fasi diverse del workflow di Git:<\/p>\n Troverete gli hook nella directory Gli hook si attivano durante varie azioni di Git. Ad esempio, un hook pre-commit viene eseguito quando eseguite il commit delle modifiche e un hook pre-push si attiva prima di eseguire il push in remoto<\/a>. Una volta che avrete compreso meglio questi trigger, potrete distribuire gli hook in modo pi\u00f9 strategico per rafforzare il controllo di qualit\u00e0 e ottimizzare il vostro flusso di lavoro.<\/p>\n Creare e installare gli hook Git personalizzati di base pu\u00f2 essere un processo complesso. Tuttavia, i fondamenti che utilizzeremo qui serviranno per sviluppare in seguito degli hook avanzati. Vediamo alcuni concetti che si applicano a tutti gli hook che creiamo e installiamo.<\/p>\n L’impiego del tipo di hook giusto per il proprio caso d’uso specifico \u00e8 un primo passo importante da compiere. Innanzitutto, \u00e8 necessario capire il vostro workflow e le vostre esigenze di sviluppo. Ecco una rapida lista di considerazioni a riguardo:<\/p>\n A questo punto, dovreste essere in grado di definire obiettivi chiari per l’hook. Pu\u00f2 anche darsi che ogni obiettivo richieda un tipo di hook diverso. Tuttavia, anche se la tentazione di creare script per ogni possibile scenario \u00e8 forte, \u00e8 bene concentrarsi prima sui punti critici.<\/p>\n Denominare e posizionare correttamente gli hook Git personalizzati \u00e8 fondamentale per garantirne la funzionalit\u00e0 e la manutenibilit\u00e0. Come le funzioni, i file, i nomi delle classi e altro ancora del codice, anche gli hook Git dovrebbero avere una convenzione di denominazione coerente e descrittiva.<\/p>\n Se gli hook dovranno supportare pi\u00f9 progetti nel tempo come template, potreste voler utilizzare dei prefissi, magari con le iniziali degli sviluppatori, un dipartimento o il nome di un’azienda. In generale, i Git Hook utilizzano lettere minuscole e trattini per una maggiore leggibilit\u00e0: ad esempio, mio-progetto-pre-commit<\/b>.<\/p>\n Inoltre, mentre potete memorizzare gli hook Git nella cartella .git\/hooks<\/b> del vostro repo, gli hook personalizzati<\/i> dovrebbero essere inseriti in una cartella separata all’interno della cartella principale del progetto. In questo modo si eviteranno sovrascritture accidentali durante un aggiornamento di Git. Tuttavia, dovreste implementare il controllo di versione<\/a> per questi hook insieme al resto del codice del vostro progetto.<\/p>\n Il modo tipico per scrivere un hook Git di base \u00e8 quello di creare un nuovo file con il nome dell’hook scelto (ad esempio pre-commit<\/b>) nella directory degli hook. Elencheremo i nomi degli hook pi\u00f9 avanti quando parleremo dei parametri.<\/p>\n Prima di aprire un file per lavorarci, dovete assicurarvi che sia eseguibile utilizzando il seguente frammento di riga di comando:<\/p>\n Ricordatevi di sostituire i placeholder con le informazioni corrette. Faremo riferimento a questo snippet in tutto il post, poich\u00e9 dovrebbe essere un’azione tipica ogni volta che si crea un nuovo hook Git.<\/p>\n Una volta che il file \u00e8 eseguibile e aperto, aggiungete la vostra logica personalizzata utilizzando il linguaggio di scripting che preferite. Pu\u00f2 trattarsi di Bash, Python<\/a>, Ruby<\/a> e altri. La creazione di questi linguaggi va ovviamente al di l\u00e0 dell’argomento che tratteremo in questa sede. Tuttavia, in seguito sono previsti alcuni esempi di pseudocodice per illustrare casi d’uso e scenari specifici.<\/p>\n Infine, prima di effettuare il commit di qualsiasi modifica, testate il vostro hook tentando di eseguire l’azione correlata (come ad esempio il commit). Questo \u00e8 l’approccio di base alla creazione di Git Hook, ma ci sono molti casi d’uso avanzati. Li analizzeremo nel prossimo paragrafo.<\/p>\n La creazione di Git Hook di livello base sar\u00e0 un’attivit\u00e0 che eseguirete spesso nel corso della vostra carriera di sviluppatori. Tuttavia, in molte situazioni sono necessari hook pi\u00f9 avanzati e complessi. Di seguito vedremo alcuni casi d’uso e alcuni esempi di hook per una serie di scenari comuni.<\/p>\n L’utilizzo di un linter per imporre lo stile del codice \u00e8 un’applicazione fantastica per gli hook di Git. Pu\u00f2 aiutare a mantenere la qualit\u00e0 del codice coerente in tutto il repository e dovrebbe essere un’applicazione molto utile.<\/p>\n Naturalmente, dovrete scegliere un linter che si adatti al linguaggio di programmazione del vostro progetto. Ad esempio, Black<\/a> \u00e8 fantastico per Python. Qui useremo ESLint<\/a> per JavaScript per creare un hook di pre-commit.<\/p>\n Per prima cosa, installate il linter come pacchetto globale o locale all’interno del vostro progetto. A tal fine avrete bisogno di Node.js<\/a> e npm<\/a>:<\/p>\n Successivamente, andate alla directory degli hooks all’interno del vostro repo. Create il vostro file di pre-commit, quindi scrivete uno script che esegua il linter sui vostri file in fase di stage. L’hook deve impedire il commit se il linter trova dei problemi. Ecco un esempio approssimativo:<\/p>\n Una volta che vi sarete assicurati che l’hook sia eseguibile, testatelo con un commit. L’hook pre-commit dovrebbe eseguire il linter. Se ci sono violazioni dello stile del codice, non potrete completare il commit finch\u00e9 non avrete risolto i problemi.<\/p>\n Naturalmente, dovreste scrivere un hook che funzioni con il vostro linguaggio di programmazione<\/a> e il vostro linter, in base al vostro progetto. Ad esempio, potreste estendere questo esempio con le impostazioni di configurazione di linter, integrandolo con il vostro processo di build e altro ancora.<\/p>\n L’implementazione di un hook pre-commit per eseguire i test prima di un commit \u00e8 un modo eccellente per individuare tempestivamente eventuali problemi. In questo modo, potrete assicurarvi di eseguire il commit solo di codice affidabile.<\/p>\n Per questo esempio, utilizzeremo il framework di testing Jest<\/a> per JavaScript. Dovrete installare qualcosa di adatto al vostro progetto (come sempre):<\/p>\n Come per ogni hook, andate nella cartella degli hook, create un nuovo file, dategli un nome e rendetelo eseguibile. Da qui, scrivete uno script che esegua i test su tutti i file in fase di commit. Ecco un modello approssimativo:<\/p>\n Quando si tenta di eseguire il commit delle modifiche, l’hook eseguir\u00e0 i test sui file in fase di stage. Il commit si interromper\u00e0 per qualsiasi test fallito e dovrete risolvere i problemi prima di eseguire nuovamente il commit.<\/p>\n Un modo eccellente per semplificare il processo di rilascio \u00e8 automatizzare il versioning e il tagging all’interno di Git. In questo modo si garantir\u00e0 un versioning coerente in tutta la base di codice.<\/p>\n Per iniziare, scegliete uno schema di versioning adatto al vostro progetto. Questo esula dallo scopo dell’articolo, ma gli schemi pi\u00f9 comuni includono il Semantic Versioning (SemVer) o un modello di versioning personalizzato.<\/p>\n Poi, decidete esattamente cosa far\u00e0 il vostro hook. Ad esempio, potrebbe leggere la versione corrente, incrementarla secondo lo schema scelto e aggiornare i file necessari con la nuova versione. Dovrete anche scrivere uno script per la creazione di tag in base alla versione che utilizzi i comandi Git per creare tag leggeri o annotati.<\/p>\n Una volta creati e impostati i permessi per il vostro file, potete iniziare a scrivere il vostro hook. Pu\u00f2 trattarsi di un hook complesso e molto specifico che pu\u00f2 anche cambiare da progetto a progetto. Tuttavia, la maggior parte degli hook di questo tipo include i seguenti elementi:<\/p>\n Da qui, lo script deve aggiornare il file di versione con il nuovo numero, creare un tag leggero con la nuova versione e, facoltativamente, inviare il nuovo tag a un repository remoto. Una volta effettuate le modifiche, l’hook far\u00e0 in modo che ogni commit sia associato a una versione e a un tag appropriati.<\/p>\n Probabilmente vorrete adattare ulteriormente questo hook alle esigenze del vostro progetto. Ad esempio, potreste gestire casi come la creazione di tag iniziali, la gestione dei conflitti di versione e l’aggiornamento dei riferimenti di versione nei file.<\/p>\n Uno dei motivi per cui gli hook di Git sono cos\u00ec potenti \u00e8 il modo in cui gestiscono le variabili dinamiche. Tuttavia, questo pu\u00f2 essere un concetto complesso da comprendere. Di seguito analizzeremo sia le variabili d’ambiente che i parametri degli hook, iniziando da questi ultimi.<\/p>\n Gli hook possono ricevere parametri specifici da Git per accedere a informazioni contestuali dalla vostra base di codice principale. Git imposta i parametri in modo automatico al momento dell’esecuzione e, sebbene nella maggior parte dei casi non sia necessario definirli, potrebbe essere necessario dichiararli. \u00c8 essenziale comprenderli per sviluppare degli hook efficaci.<\/p>\n Ecco una panoramica dei punti chiave dei parametri degli hook:<\/p>\n Se doveste aggiungere un parametro che l’hook non pu\u00f2 chiamare, lo script non sar\u00e0 generalmente in grado di utilizzarlo. I parametri sono specifici per un particolare hook e contesto di esecuzione. Per evitare problemi, dovreste utilizzare solo parametri documentati. Tuttavia, potete<\/i> assegnare il valore di un parametro posizionale a un’altra variabile e poi utilizzarlo nel vostro script:<\/p>\n In questo caso, la variabile Tenete presente che in alcuni casi utilizzerete lo standard input ( Poich\u00e9 ogni hook di Git avr\u00e0 i suoi parametri, \u00e8 probabile che abbiate bisogno di un riferimento per sapere quali sono per la vostra specifica applicazione. La buona notizia \u00e8 che ci sono alcuni modi per farlo.<\/p>\n Ad esempio, la documentazione ufficiale degli hook Git<\/a> include alcuni dei parametri pi\u00f9 comuni. Tuttavia, l’approccio migliore \u00e8 quello di aprire uno dei Git hook di esempio. Questi consistono in una mini-guida su come eseguire lo script dell’hook e includono le definizioni dei parametri:<\/p>\n Questi esempi sono un ottimo modo per familiarizzare con gli hook Git e possono anche farvi fare un po’ di strada quando si tratta di codificarli.<\/p>\n I Git Hook possono recuperare argomenti da quelli della riga di comando e da Queste variabili d’ambiente<\/a> permettono di personalizzare il comportamento dei vostri Git Hook e di prendere decisioni basate su vari aspetti del flusso di lavoro Git. In questo modo, potete creare dei Git Hook dinamici e consapevoli del contesto. Ad esempio, potete usarli per convalidare i messaggi di commit, controllare l’accesso a branch specifici o attivare azioni personalizzate in base all’identit\u00e0 dell’autore.<\/p>\n Elencare tutte le variabili d’ambiente va oltre lo scopo di questo post. Vi consigliamo di consultare la documentazione di Git<\/a> e gli hook di esempio per avere indicazioni sulle variabili da utilizzare.<\/p>\n In genere Git imposta automaticamente diverse variabili d’ambiente a seconda dell’hook che chiama. Questo pu\u00f2 causare dei problemi se non siete a conoscenza delle variabili impostate. Ad esempio, prendiamo il seguente risultato per la variabile Fortunatamente, c’\u00e8 un modo per verificare cosa fa Git<\/a> con le variabili d’ambiente utilizzando un piccolo snippet all’interno del vostro hook:<\/p>\n Per riassumere il codice, la riga due stampa lo script in esecuzione; la riga tre imposta tutte le variabili d’ambiente da visualizzare, quindi filtra quelle con “GIT” nel nome; la riga quattro stampa la directory di lavoro corrente.<\/p>\n Una volta eseguito, vedrete l’output corrispondente alle variabili d’ambiente associate al vostro hook. Da qui avrete le conoscenze necessarie per assicurarvi che i vostri Git Hook possano utilizzare le variabili d’ambiente nel modo che preferite.<\/p>\n La gestione degli hook Git all’interno di un team o di un’azienda \u00e8 fondamentale per garantire pratiche di sviluppo coerenti e automatizzare i flussi di lavoro<\/a> in modo efficiente. Per esempio, prendiamo il semplice atto di assegnare una directory dedicata agli hook. Possiamo darvi due consigli:<\/p>\n Pi\u00f9 \u00e8 probabile che gli hook vengano utilizzati in pi\u00f9 progetti, maggiore \u00e8 l’importanza della documentazione. dovreste mantenere una documentazione completa che illustri lo scopo, l’uso e le opzioni di configurazione di ogni hook all’interno del repo. Anche le revisioni del codice e le strategie di aggiornamento per questi hook globali saranno essenziali.<\/p>\n Vi consigliamo anche di archiviare gli hook personalizzati nel sistema di controllo delle versioni (VCS) insieme alla base di codice del vostro progetto. In questo modo si garantisce che tutto il team abbia accesso all’intera libreria di hook.<\/p>\n Gli hook lato server vengono eseguiti sul server che ospita il repo Git centrale. In questo modo, potete applicare le politiche, eseguire controlli o attivare azioni sul lato server.<\/p>\n Avete due opzioni di archiviazione per i vostri hook lato server: all’interno del VCS insieme al vostro progetto o in repository separati.<\/p>\n L’utilizzo del VCS per memorizzare gli hook lato server<\/a> presenta due vantaggi. Innanzitutto, potete assicurarvi che gli hook abbiano lo stesso versioning e la stessa manutenzione del resto della base di codice. In secondo luogo, dovrete clonare un solo repository per accedere sia al codice del progetto che agli hook.<\/p>\n Tuttavia, a seconda della natura degli hook specifici, archiviarli nello stesso repository potrebbe sollevare problemi di sicurezza nel caso in cui tali hook accedano a informazioni sensibili. Inoltre, se gli hook sono complessi o richiedono configurazioni specifiche, potrebbe aumentare la complessit\u00e0 del vostro repo principale.<\/p>\n Mantenere gli hook lato server in repository separati permette di aggiornarli e di modificarli indipendentemente dalla base di codice, riducendo cos\u00ec i potenziali conflitti. Questa modularit\u00e0 pu\u00f2 offrire una maggiore flessibilit\u00e0.<\/p>\n Inoltre, potete conservare gli hook in repository ad accesso limitato. Questo aiuter\u00e0 a ridurre il rischio di esposizione di dati sensibili.<\/p>\n Al contrario, la gestione di pi\u00f9 repository<\/a> potrebbe richiedere uno sforzo aggiuntivo. Inoltre, se gli hook si basano su versioni specifiche della vostra base di codice principale, pu\u00f2 essere difficile coordinare le modifiche tra i repository.<\/p>\n Automatizzare l’installazione degli hook su pi\u00f9 repository pu\u00f2 far risparmiare tempo e garantire la coerenza del flusso di sviluppo. Utilizzando script e template, potete impostare facilmente gli hook nei vari repository senza dover intervenire manualmente.<\/p>\n Il processo inizia con un repository dedicato che contiene gli hook globali. Dovrete standardizzarli: per esempio, evitate di codificare percorsi o valori specifici per un singolo repository.<\/p>\n Da qui potete iniziare a scrivere il vostro script di installazione. Ad esempio, il seguente pseudocodice cloner\u00e0 il repo modello di un hook e copier\u00e0 (o “linker\u00e0”)<\/a> gli hook nella directory .git\/hooks<\/b> di ogni repository:<\/p>\n Una volta salvate le modifiche, potete eseguire lo script di installazione per ogni repo in cui volete installare gli hook:<\/p>\n Apportate le modifiche nel repository del modello ogni volta che avete bisogno di aggiornare o aggiungere gli hook. La volta successiva che eseguirete lo script di installazione in un repository, gli hook aggiornati verranno installati.<\/p>\n I template Git permettono di definire hook e configurazioni comuni per i nuovi repository. Forniscono un approccio sistematico per aiutarvi ad automatizzare le impostazioni, le configurazioni e altri elementi quando create o clonate nuovi repository. In questo modo potete assicurarvi che ogni repository aderisca alle vostre pratiche tipiche e consolidate.<\/p>\n Una volta creata una directory template e aggiunti gli script hook, potete configurare Git in modo che utilizzi la directory come modello per i nuovi repository. Potete impostarlo su base globale o locale per ogni utente.<\/p>\n Per le configurazioni globali, puntate alla cartella template hooks:<\/p>\n Per le configurazioni locali, potete specificare il repo esatto:<\/p>\n Ogni volta che create un nuovo repository usando Infine, mentre gli hook template possono essere generici, \u00e8 anche possibile consentire la personalizzazione degli hooks in base a esigenze specifiche. Ad esempio, uno script potrebbe verificare la presenza di un file di configurazione degli hook specifico per il repository e utilizzarlo se presente.<\/p>\n L’uso degli hook Git pu\u00f2 essere molto utile per l’automazione dei processi e l’applicazione delle pratiche pi\u00f9 comuni. Tuttavia, questo pu\u00f2 comportare la possibilit\u00e0 di introdurre vulnerabilit\u00e0 se non si gestiscono bene gli hook.<\/p>\n Ecco un rapido elenco di pratiche che potreste implementare per i vostri hook:<\/p>\n Dovrete anche implementare un processo di test e revisione completo e approfondito. Questo vi aiuter\u00e0 a ridurre le vulnerabilit\u00e0 e altri errori in futuro.<\/p>\n A questo punto, dovremmo parlare dell’implementazione di una corretta convalida e gestione degli errori<\/a> per i vostri hook. Questo \u00e8 fondamentale per garantire affidabilit\u00e0, stabilit\u00e0 e sicurezza.<\/p>\n Ad esempio, dovete sempre convalidare tutti gli input o i parametri che i vostri script hook ricevono. Tuttavia, potete fare molto di pi\u00f9 per garantire una buona validazione. Potete assicurarvi che il repository sia nello stato previsto per l’esecuzione dell’hook. Ad esempio, in un hook pre-commit, controllate che i file necessari siano in fase di staging prima del commit.<\/p>\n Anche la gestione degli errori sar\u00e0 preziosa. I codici di uscita sono fondamentali sia negli hook che nella base di codice, cos\u00ec come i log degli errori e i messaggi di errore informativi. L’obiettivo dovrebbe essere il “Graceful failure”, come nel caso di codebase pi\u00f9 grandi.<\/p>\n Naturalmente, in uno scenario reale, i vostri hook potrebbero richiedere una convalida pi\u00f9 complessa e una logica di gestione degli errori. Ci\u00f2 significa che i test regolari sono ancora pi\u00f9 importanti.<\/p>\n Gli incidenti possono capitare, quindi impostare i vostri Git Hook in modo da prevenire queste azioni distruttive indesiderate \u00e8 fondamentale per salvaguardare i dati da perdite o danni. Gli hook possono essenzialmente fungere da reti di sicurezza attraverso la segnalazione da parte dell’utente di azioni potenzialmente dannose.<\/p>\n Gli hook di pre-ricezione e di pre-commit funzionano bene in questo caso. Vediamo rapidamente come entrambi possono essere utili:<\/p>\n Tuttavia, a prescindere dalle pratiche che implementerete, queste devono essere sicure, efficienti e ottimali per le vostre esigenze. Per questo \u00e8 necessaria una strategia di revisione e test approfondita.<\/p>\n La revisione e il test degli hook sono essenziali per garantire che funzionino correttamente e che siano in linea con il vostro flusso di sviluppo. Le peer review, una documentazione chiara, l’abbondanza di commenti e altro ancora possono aiutare a garantire che gli hook siano pronti per la produzione.<\/p>\n Quando si tratta di testare, \u00e8 importante farlo in modo isolato utilizzando dati campione diversi. Potreste anche implementare test di regressione o di integrazione automatizzati.<\/p>\n Infine, vi consigliamo di testare gli hook in ambienti diversi (come i server<\/a> di sviluppo<\/a>, di staging<\/a> e di produzione<\/a>) per assicurarvi che abbiano un comportamento coerente. Una configurazione di log in tempo reale vi aiuter\u00e0 in questo senso, in quanto pu\u00f2 mostrare cosa succede quando i dati si spostano da un server all’altro.<\/p>\n Come in ogni base di codice, anche in questo caso potreste dover risolvere problemi legati agli hook, anche con diversi tentativi. Infatti, a prescindere dal tipo di hook Git, troverete sempre gli stessi errori. Molti di questi sono semplici problemi che riguardano tutti i tipi di progetti, come errori di sintassi, problemi di permessi, utilizzo di percorsi relativi o hardcoded e molto altro ancora.<\/p>\n Tuttavia, \u00e8 una buona idea controllare che non ci siano dipendenze mancanti, poich\u00e9 alcuni hook si basano su strumenti, file o librerie esterne. Per questo motivo, dovete renderli disponibili nell’ambiente in cui eseguite l’hook.<\/p>\n Ci sono per\u00f2 dei problemi specifici che possono verificarsi con gli hook di Git. Ad esempio, gli hook dovrebbero uscire con un codice di stato diverso da zero per indicare un fallimento. Inoltre, gli hook non dovrebbero contenere loop infiniti. Senza questi due elementi, potreste causare un comportamento inaspettato e interrompere il workflow.<\/p>\n Potreste anche scoprire che i conflitti tra due hook provocano interazioni e conseguenze indesiderate. Anche le cosiddette “race condition”<\/a> possono ostacolare le vostre aspettative. Questo accade quando due o pi\u00f9 hook si attivano attraverso eventi simili, ma uno si completa prima dell’altro: questo avr\u00e0 un impatto sul risultato finale che vi aspettate.<\/p>\n \u00c8 qui che le revisioni e i test diventano fondamentali. Anche il mantenimento della documentazione \u00e8 importante per evitare problemi e garantire che gli hook funzionino come ci si aspetta.<\/p>\n A proposito di documentazione, il materiale di riferimento di Git<\/a> \u00e8 una lettura essenziale. In effetti, insieme a questo articolo e forse al sito indipendente della guida agli hook di Git<\/a> (utilizzando GitHub Pages<\/a>), non dovreste aver bisogno di molto altro materiale da leggere.<\/p>\n Tuttavia, potreste voler dare un’occhiata anche alle applicazioni che aiutano a gestire i Git hook. Lefthook<\/a> ha aggiornamenti regolari e un sacco di supporto su GitHub, mentre Husky<\/a> \u00e8 ottimo per il linting dei messaggi di commit.<\/p>\n Le pipeline CI\/CD funzionano bene con gli hook di Git, in quanto questi script possono aiutarvi ad automatizzare le attivit\u00e0, garantire una qualit\u00e0 costante e fornire controlli di sicurezza.<\/p>\n Ad esempio, gli hook pre-commit vi permettono di eseguire controlli di qualit\u00e0 del codice, come il linting, l’analisi statica e la formattazione. Per quanto riguarda i test, potete attivare test unitari, suite di test o altri controlli automatizzati nella fase di pre-commit. Inoltre, gli hook pre-push vi permettono di eseguire test di integrazione, scansioni di sicurezza<\/a> e altro ancora.<\/p>\n Sono molti i vantaggi che potete trarre dall’uso degli hook nelle vostre pipeline CI\/CD:<\/p>\n Poich\u00e9 l’API di Kinsta<\/a> permette di impostare pipeline CI\/CD<\/a>, potete integrare anche gli hook Git. Kinsta vi permette di scaricare l’intero repo<\/a> da una postazione remota e consente di effettuare push utilizzando un plugin di terze parti come WP Pusher<\/a>.<\/p>\n Naturalmente, ci\u00f2 significa che avete anche la possibilit\u00e0 di utilizzare i Git hook. In questo modo, la vostra installazione di Kinsta pu\u00f2 sfruttare questi potenti script all’interno del vostro repo.<\/p>\n\n
.git\/hooks<\/code> del repository Git. Ci sono anche degli esempi di hook: potete usarli come template per creare i vostri script personalizzati. Gli hook coprono una serie di azioni e utilizzano il prefisso sample-<\/b> come riferimento:<\/p>\n![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/sample-hooks-directory.png\" "\\"Sample")
Come creare e installare gli hook Git personalizzati<\/h2>\n
Scegliere un tipo di hook appropriato<\/h3>\n
\n
Dare un nome e posizionare gli hook Git personalizzati<\/h3>\n
Come creare un hook Git personalizzato di livello base<\/h3>\n
chmod +x path\/to\/file\/hook-name<\/code><\/pre>\nCome creare e installare hook personalizzati avanzati<\/h2>\n
Creare un hook che imponga lo stile del codice usando i linter<\/h3>\n
npm install eslint --save-dev<\/code><\/pre>\n#!\/bin\/sh\n\n# Stash unstaged changes (optional but recommended)\ngit stash -q --keep-index\n\n# Run the linter on staged files\nnpm run lint # Replace with the appropriate linting command\nLINT_RESULT=$?\n\n# Unstash the stashed changes (optional but recommended)\ngit stash pop -q\n\n# Exit with the linter's exit code\nexit $LINT_RESULT<\/code><\/pre>\nImplementare un hook per eseguire i test prima di un commit<\/h3>\n
npm install jest --save-dev<\/code><\/pre>\n#!\/bin\/sh\n\n# Stash unstaged changes (optional but recommended)\ngit stash -q --keep-index\n\n# Run tests on staged files\nnpm test # Replace with the appropriate test command\nTEST_RESULT=$?\n\n# Unstash the stashed changes (optional but recommended)\ngit stash pop -q\n\n# Exit with the test's exit code\nexit $TEST_RESULT<\/code><\/pre>\nSviluppare un hook per automatizzare il versioning e il tagging<\/h3>\n
\n
1.2.3<\/code>) e restituisce la nuova versione.<\/li>\n0<\/code> per major, 1<\/code> per minor, 2<\/code> per patch.<\/li>\n<\/ul>\nCapire i parametri dell’hook e le variabili d’ambiente<\/h2>\n
Come i parametri passano agli hook<\/h3>\n
\n
$1<\/code> si riferisce al primo parametro, $2<\/code> al secondo parametro e cos\u00ec via. Questi parametri non sono arbitrari: hanno significati e scopi specifici. Per questo motivo, anche se non sono “ufficiali”, rappresentano delle convenzioni accettate per accedere ai valori dei parametri.<\/li>\n$1<\/code> spesso contiene il percorso di un file mentre $2<\/code> potrebbe essere la fonte di un’azione.<\/li>\n<\/ul>\n#!\/bin\/sh\n\n# Assign $1 to the variable EXAMPLE\nEXAMPLE=$1\n\n# Use EXAMPLE variable\necho \"The commit message file is: $EXAMPLE\"<\/code><\/pre>\nEXAMPLE<\/code> avr\u00e0 lo stesso valore di $1<\/code>, che \u00e8 il percorso del file del messaggio di commit. Tuttavia, l’utilizzo dei nomi delle variabili documentati rende il codice pi\u00f9 comprensibile.<\/p>\nstdin<\/code>)<\/a> per definire i parametri, nel qual caso dovrete inserire questi elementi nei vostri hook.<\/p>\nTrovare i valori e le definizioni dei parametri degli hook Git<\/h4>\n
![\"Un](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/sample-git-hook.png\")
Variabili d’ambiente<\/h3>\n
stdin,<\/code>, come abbiamo detto. Tuttavia, possono anche recuperare argomenti dall’ambiente stesso mentre viene eseguito all’interno della shell bash<\/code>.<\/p>\nTestare i valori delle variabili d’ambiente<\/h3>\n
GIT_REFLOG_ACTION<\/code> per gli hook pre-rebase e post-merge:<\/p>\n\n
pre-rebase<\/code>. GIT_REFLOG_ACTION=rebase<\/code><\/li>\npost-merge<\/code>. GIT_REFLOG_ACTION=\u2019pull other master\u2019<\/code><\/li>\n<\/ul>\n#!\/bin\/bash\n\necho Running $BASH_SOURCE\nset | egrep GIT\necho PWD is $PWD<\/code><\/pre>\nConsigli e trucchi per gestire e condividere i vostri Git Hook<\/h2>\n
\n
Usare gli hook Git lato server<\/h3>\n
Memorizzare gli hook lato server usando un VCS<\/h4>\n
Conservare gli hook lato server in repository separati<\/h4>\n
Automatizzare l’installazione degli hook<\/h3>\n
# Example installation script\n# Usage: .\/install_hooks.sh \/path\/to\/repository\nTEMPLATE_REPO=\"https:\/\/github.com\/yourusername\/hooks-template.git\"\nREPO_PATH=\"$1\"\nREPO_NAME=$(basename \"$REPO_PATH\")\n\n# Clone the template repository\ngit clone --depth 1 \"$TEMPLATE_REPO\" \"$REPO_NAME-hooks\"\n\n# Copy or symlink hooks to the repository\ncp -r \"$REPO_NAME-hooks\/hooks\" \"$REPO_PATH\/.git\/\"\nrm -rf \"$REPO_NAME-hooks\"\necho \"Hooks installed in $REPO_NAME\u201d<\/code><\/pre>\n.\/install_hooks.sh \/path\/to\/repository1\n.\/install_hooks.sh \/path\/to\/repository2\n# \u2026<\/code><\/pre>\nTemplate Git<\/h3>\n
git config --global init.templateDir \/path\/to\/hooks-template<\/code><\/pre>\ngit init --template=\/path\/to\/hooks-template<\/code><\/code><\/pre>\ngit init<\/code> o clonate un repository esistente, Git copier\u00e0 automaticamente il contenuto della directory degli hook template nella directory .git<\/b> del nuovo repo.<\/p>\nPratiche comuni per mantenere sicuri gli hook Git<\/h2>\n
\n
Convalida<\/h3>\n
![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/hook-exit-code.png\")
Azioni distruttive accidentali<\/h3>\n
\n
--force<\/code>) o la cancellazione di branch<\/a>.<\/li>\nforce push<\/code> nei messaggi di commit. A questo punto, mostrate un messaggio di avvertimento o di errore per l’utente.<\/li>\n<\/ul>\nRevisione e test degli hook Git<\/h3>\n
Come risolvere i problemi degli hook<\/h2>\n
![\"Il](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/git-hooks-website.png\")
I vantaggi dell’integrazione degli hooks nelle pipeline di integrazione continua (CI\/CD)<\/h2>\n
\n
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/wppusher-home-page.png\")
Riepilogo<\/h2>\n