Close

Hook Git

Gli hook Git sono script che vengono eseguiti automaticamente ogni volta che si verifica un evento specifico in un repository Git. Ti consentono di personalizzare il comportamento interno di Git e di attivare azioni personalizzabili nei punti chiave del ciclo di vita dello sviluppo.

Hook in esecuzione durante il processo di creazione del commit

I casi d'uso più comuni degli hook Git includono la promozione di una policy di commit, la modifica dell'ambiente del progetto in base allo stato del repository e l'implementazione di flussi di lavoro di continuous integration. Tuttavia, poiché gli script sono personalizzabili in modo illimitato, puoi usare gli hook Git per automatizzare o ottimizzare praticamente qualsiasi aspetto del flusso di lavoro relativo allo sviluppo.

In questo articolo, inizieremo con una panoramica concettuale di come funzionano gli hook Git. Proseguiremo, quindi, con alcuni degli hook più richiesti da utilizzare nei repository locali e lato server.


Panoramica concettuale


Tutti gli hook Git sono script ordinari che Git esegue quando si verificano determinati eventi nel repository. Questo li rende molto facili da installare e configurare.

Gli hook possono risiedere nei repository locali o lato server e vengono eseguiti solo in risposta alle azioni del repository specifico. Esamineremo concretamente le categorie di hook più avanti in questo articolo. La configurazione descritta nella restante parte di questa sezione si applica sia agli hook locali che a quelli lato server.

Installazione di hook

Gli hook risiedono nella directory .git/hooks di ogni repository Git. Git popola automaticamente questa directory con script di esempio quando inizializzi un repository. All'interno di .git/hooks si trovano i seguenti file:

applypatch-msg.sample       pre-push.sample
commit-msg.sample           pre-rebase.sample
post-update.sample          prepare-commit-msg.sample
pre-applypatch.sample       update.sample
pre-commit.sample
Database
materiale correlato

Come spostare un repository Git completo

Logo di Bitbucket
Scopri la soluzione

Impara a utilizzare Git con Bitbucket Cloud

Questi file rappresentano la maggior parte degli hook disponibili, ma l'estensione .sample ne impedisce l'esecuzione per impostazione predefinita. Per "installare" un hook, devi solo rimuovere l'estensione .sample . In alternativa, se scrivi un nuovo script da zero, puoi semplicemente aggiungere un nuovo file che corrisponde ai nome file riportati sopra, tranne l'estensione .sample .

Ad esempio, prova a installare un semplice hook prepare-commit-msg. Rimuovi l'estensione file .sample dallo script e aggiungi quanto segue al file:

#!/bin/sh

echo "# Please include a useful commit message!" > $1

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:

chmod +x prepare-commit-msg

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).

Linguaggi di scripting

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.

#!/usr/bin/env python

import sys, os

commit_msg_filepath = sys.argv[1]
with open(commit_msg_filepath, 'w') as f:
    f.write("# Please include a useful commit message!")

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.

Ambito degli hook

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.

Hook in esecuzione durante il processo di creazione del commit

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.

Hook locali


Gli hook locali interessano solo il repository in cui risiedono. Mentre leggi questa sezione, ricorda che ogni sviluppatore può modificare i propri hook locali, quindi non puoi utilizzarli per applicare una policy di commit. Tuttavia, possono rendere molto più semplice per gli sviluppatori il rispetto di determinate linee guida. In questa sezione, esploreremo sei degli hook locali più utili:

  • 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.

pre-commit

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).

#!/bin/sh

# Check if this is the initial commit
if git rev-parse --verify HEAD >/dev/null 2>&1
then
    echo "pre-commit: About to create a new commit..."
    against=HEAD
else
    echo "pre-commit: About to create the first commit..."
    against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# Use git diff-index to check for whitespace errors
echo "pre-commit: Testing for whitespace errors..."
if ! git diff-index --check --cached $against
then
    echo "pre-commit: Aborting commit due to whitespace errors"
    exit 1
else
    echo "pre-commit: No whitespace errors :)"
    exit 0
fi

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.

Preparazione di un messaggio di conferma

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.

#!/usr/bin/env python

import sys, os, re
from subprocess import check_output

# Collect the parameters
commit_msg_filepath = sys.argv[1]
if len(sys.argv) > 2:
    commit_type = sys.argv[2]
else:
    commit_type = ''
if len(sys.argv) > 3:
    commit_hash = sys.argv[3]
else:
    commit_hash = ''

print "prepare-commit-msg: File: %s\nType: %s\nHash: %s" % (commit_msg_filepath, commit_type, commit_hash)

# Figure out which branch we're on
branch = check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip()
print "prepare-commit-msg: On branch '%s'" % branch

# Populate the commit message with the issue #, if there is one
if branch.startswith('issue-'):
    print "prepare-commit-msg: Oh hey, it's an issue branch."
    result = re.match('issue-(.*)', branch)
    issue_number = result.group(1)

    with open(commit_msg_filepath, 'r+') as f:
        content = f.read()
        f.seek(0, 0)
        f.write("ISSUE-%s %s" % (issue_number, content))

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.

ISSUE-224 

# Please enter the commit message for your changes. Lines starting 
# with '#' will be ignored, and an empty message aborts the commit. 
# On branch issue-224 
# Changes to be committed: 
#   modified:   test.txt

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.

Messaggio di commit

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.

#!/usr/bin/env python

import sys, os, re
from subprocess import check_output

# Collect the parameters
commit_msg_filepath = sys.argv[1]

# Figure out which branch we're on
branch = check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip()
print "commit-msg: On branch '%s'" % branch

# Check the commit message if we're on an issue branch
if branch.startswith('issue-'):
    print "commit-msg: Oh hey, it's an issue branch."
    result = re.match('issue-(.*)', branch)
    issue_number = result.group(1)
    required_message = "ISSUE-%s" % issue_number

    with open(commit_msg_filepath, 'r') as f:
        content = f.read()
        if not content.startswith(required_message):
            print "commit-msg: ERROR! The commit message must start with '%s'" % required_message
            sys.exit(1)

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.

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.

#!/usr/bin/env python

import smtplib
from email.mime.text import MIMEText
from subprocess import check_output

# Get the git log --stat entry of the new commit
log = check_output(['git', 'log', '-1', '--stat', 'HEAD'])

# Create a plaintext email message
msg = MIMEText("Look, I'm actually doing some work:\n\n%s" % log)

msg['Subject'] = 'Git post-commit hook notification'
msg['From'] = 'mary@example.com'
msg['To'] = 'boss@example.com'

# Send the message
SMTP_SERVER = 'smtp.example.com'
SMTP_PORT = 587

session = smtplib.SMTP(SMTP_SERVER, SMTP_PORT)
session.ehlo()
session.starttls()
session.ehlo()
session.login(msg['From'], 'secretPassword')

session.sendmail(msg['From'], msg['To'], msg.as_string())
session.quit()

È 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.

post-checkout

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:

#!/usr/bin/env python

import sys, os, re
from subprocess import check_output

# Collect the parameters
previous_head = sys.argv[1]
new_head = sys.argv[2]
is_branch_checkout = sys.argv[3]

if is_branch_checkout == "0":
    print "post-checkout: This is a file checkout. Nothing to do."
    sys.exit(0)

print "post-checkout: Deleting all '.pyc' files in working directory"
for root, dirs, files in os.walk('.'):
    for filename in files:
        ext = os.path.splitext(filename)[1]
        if ext == '.pyc':
            os.unlink(os.path.join(root, filename))

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.

pre-rebase

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:

#!/bin/sh

# Disallow all rebasing
echo "pre-rebase: Rebasing is dangerous. Don't do it."
exit 1

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

pre-rebase: Rebasing is dangerous. Don't do it.
The pre-rebase hook refused to rebase.

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.

Hook lato server


Gli hook lato server funzionano proprio come quelli locali, ad eccezione del fatto che risiedono nei repository lato server (ad esempio, un repository centrale o un repository pubblico dello sviluppatore). Quando vengono allegati al repository ufficiale, alcuni possono essere utili per applicare la policy rifiutando determinati commit.

Ci sono tre hook lato server di cui parleremo nella restante parte di questo articolo:

  • 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.

pre-receive

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:

<old-value> <new-value> <ref-name>

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

#!/usr/bin/env python

import sys
import fileinput

# Read in each ref that the user is trying to update
for line in fileinput.input():
    print "pre-receive: Trying to push ref: %s" % line

# Abort the push
# sys.exit(1)

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:

b6b36c697eb2d24302f89aa22d9170dfe609855b 85baa88c22b52ddd24d71f05db31f4e46d579095 refs/heads/main

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.

Aggiornamento

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.

#!/usr/bin/env python

import sys

branch = sys.argv[1]
old_commit = sys.argv[2]
new_commit = sys.argv[3]

print "Moving '%s' from %s to %s" % (branch, old_commit, new_commit)

# Abort pushing only this branch
# sys.exit(1)

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.

post-receive

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.

Riepilogo


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.


Condividi l'articolo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Le persone collaborano utilizzando una parete piena di strumenti

Blog di Bitbucket

Illustrazione su Devops

Percorso di apprendimento DevOps

Funzione Demo Den per demo con esperti Atlassian

Come Bitbucket Cloud funziona con Atlassian Open DevOps

Iscriviti alla nostra newsletter DevOps

Thank you for signing up