Domanda

Vorremmo creare alcuni script hook di base che tutti possiamo condividere - per cose come i messaggi di commit pre-formattazione. Git ha script hook per quello che sono normalmente memorizzati in <project>/.git/hooks/. Tuttavia, tali script non vengono propagati quando le persone eseguono un clone e non sono controllate dalla versione.

C'è un buon modo per aiutare tutti a ottenere gli script hook giusti? Posso semplicemente fare in modo che quegli script hook rimandino a script controllati dalla versione nel mio repository?

È stato utile?

Soluzione

Teoricamente, potresti creare una hooks directory (o qualunque nome tu preferisca) nella directory del tuo progetto con tutti gli script, e poi collegarli simbolicamente in .git/hooks. Naturalmente, ogni persona che ha clonato il repository dovrebbe impostare questi collegamenti simbolici (anche se potresti essere davvero fantasioso e avere uno script di distribuzione che il clonatore potrebbe eseguire per configurarli in modo semi-automatico).

Per eseguire il collegamento simbolico su * nix, tutto ciò che devi fare è:

root="$(pwd)"
ln -s "$root/hooks" "$root/.git/hooks"

usa ln -sf se sei pronto a sovrascrivere cosa c'è in <=>

Altri suggerimenti

In Git 2.9 , il l'opzione di configurazione core.hooksPath specifica una directory di hook personalizzati.

Sposta i tuoi hook in una hooks directory tracciata nel tuo repository. Quindi, configura ogni istanza del repository per utilizzare il $GIT_DIR/hooks tracciato anziché man githooks:

git config core.hooksPath hooks

In generale, il percorso può essere assoluto o relativo alla directory in cui vengono eseguiti gli hook (in genere la radice dell'albero di lavoro; vedere la sezione DESCRIZIONE di <=> ).

Se il tuo progetto è un progetto JavaScript e utilizzi npm come gestore di pacchetti puoi utilizzare condiviso -git-hooks per imporre githook su npm install.

Che ne dici di git-hooks , instrada .git/hooks invoca nello script sotto directory di progetto githooks.

Ci sono anche molte funzionalità che ti consentono di ridurre al minimo il gancio di copia e collegamento simbolico ovunque.

La maggior parte dei moderni linguaggi di programmazione, o meglio i loro strumenti di compilazione, supportano i plugin per gestire i git hook. Ciò significa che tutto ciò che devi fare è configurare package.json, pom.xml, ecc., E chiunque nel tuo team non avrà altra scelta se non quella di conformarsi a meno che non modifichi il file di build. Il plugin aggiungerà contenuto alla directory .git per te.

Esempi:

https://github.com/olukyrich/githook-maven-plugin

https://www.npmjs.com/package/git-hooks

Stiamo usando le soluzioni di Visual Studio (e quindi i progetti) che hanno eventi pre e post build. Sto aggiungendo un ulteriore progetto chiamato 'GitHookDeployer'. Il progetto modifica automaticamente un file nell'evento post build. Quel file è impostato per essere copiato nella directory di generazione. Pertanto, il progetto viene creato ogni volta e non viene mai ignorato. Nell'evento build, si assicura anche che tutti gli hook git siano a posto.

Nota che questa non è una soluzione generale, poiché alcuni progetti, ovviamente, non hanno nulla da costruire.

Puoi rendere la tua cartella hooks un altro repository git e collegarla come sottomodulo ... Immagino ne valga la pena solo se molti membri e hook sono cambiati regolarmente.

È possibile utilizzare una soluzione gestita per la gestione degli hook pre-commit come pre-commit . O una soluzione centralizzata per git-hooks lato server come Datree.io . Ha politiche integrate come:

  1. Rileva e impedisce fusione di segreti .
  2. Applicare correttamente Configurazione utente Git .
  3. Applica Integrazione ticket Jira - menziona il numero del biglietto nel nome della richiesta pull / messaggio di commit.

Non sostituirà tutti i tuoi hook, ma potrebbe aiutare i tuoi sviluppatori con quelli più ovvi senza la configurazione infernale di installare i hook su ogni sviluppatori computer / repo.

Dichiarazione di non responsabilità: sono uno dei fondatori di Datrees

pre-commit lo rende facile per gli hook pre-commit. Non risponde alla domanda del PO sulla gestione di alcun hook git arbitrario, ma gli hook pre-commit sono probabilmente i più utilizzati per scopi di qualità del codice.

Idealmente, gli hook vengono scritti in bash, se si seguono i file di esempio. Ma puoi scriverlo in qualsiasi lingua disponibile e assicurarti che abbia il flag eseguibile.

Quindi, puoi scrivere un codice Python o Go per raggiungere i tuoi obiettivi e posizionarlo nella cartella hook. Funzionerà, ma non sarà gestito insieme al repository.

Due opzioni

a) Script multipli

Puoi codificare i tuoi hook all'interno del tuo aiuto e aggiungere un piccolo frammento di codice agli hook, per chiamare il tuo script perfetto, in questo modo:

$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/myprecommit.js

b) Script singolo

Un'opzione più interessante è quella di aggiungere solo uno script per governarli tutti, anziché diversi. Quindi, crei un hook / mysuperhook.go e punti ogni hook che vuoi avere.

$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/mysuperhook.go $(basename $0)

Il parametro fornirà al tuo script quale hook è stato attivato e puoi differenziarlo nel tuo codice. Perché? A volte potresti voler eseguire lo stesso controllo per commit e push, ad esempio.

E poi?

Quindi, potresti voler avere ulteriori funzionalità, come:

  • Attiva manualmente l'hook per verificare se tutto è ok anche prima di un commit o push. Se chiami semplicemente il tuo script (opzione aob) farebbe il trucco.
  • Attiva gli hook su CI, quindi non è necessario riscrivere gli stessi controlli per CI, ad esempio sarebbe solo chiamare il commit e premere i trigger. Lo stesso di quanto sopra dovrebbe risolverlo.
  • Chiama strumenti esterni, come un validatore markdown o un validatore YAML. Puoi creare syscalls e devi gestire STDOUT e STDERR.
  • Assicurati che tutti gli sviluppatori abbiano un modo semplice per installare gli hook, quindi è necessario aggiungere uno script piacevole al repository per sostituire gli hook predefiniti con quelli corretti
  • Avere alcuni helper globali, come un controllo per bloccare, si impegna a sviluppare e padroneggiare i rami, senza doverlo aggiungere a ogni repository. Puoi risolverlo avendo un altro repository con script globali.

Può essere più semplice?

Sì, esistono diversi strumenti per aiutarti a gestire git-hook. Ognuno di essi è progettato su misura per affrontare il problema da una prospettiva diversa e potrebbe essere necessario comprenderli tutti per ottenere quello che è meglio per te o la tua squadra. GitHooks.com offre molte informazioni sull'aggancio e diversi strumenti disponibili oggi.

Ad oggi, ci sono 21 progetti elencati lì con diverse strategie per gestire git hook. Alcuni lo fanno solo per un singolo hook, altri per una lingua specifica e così via.

Uno di questi strumenti, scritto da me e offerto gratuitamente come progetto opensource, si chiama hooks4git . È scritto in Python (perché mi piace) ma l'idea è quella di gestire tutti gli elementi sopra elencati in un singolo file di configurazione chiamato .hooks4git.ini, che vive all'interno del tuo repository e può chiamare qualsiasi script che desideri chiamare, in qualsiasi lingua .

L'uso di git hook è assolutamente fantastico, ma il modo in cui vengono offerti solitamente allontana le persone da esso.

Per gli utenti Nodejs una soluzione semplice è aggiornare package.json con

{
  "name": "name",
  "version": "0.0.1",
  ......
  "scripts": {
    "preinstall": "git config core.hooksPath hooks", 

La preinstallazione verrà eseguita prima

  

npm install

e reindirizza git per cercare hook all'interno della directory . \ hooks (o con qualsiasi nome tu scelga). Questa directory dovrebbe imitare . \. Git \ hooks in termini di nome del file (meno il .sample) e struttura.

Immagina che Maven e altri strumenti di costruzione abbiano un equivalente di preinstall .

Dovrebbe funzionare anche su tutte le piattaforme.

Se hai bisogno di ulteriori informazioni, consulta https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top