Zoeken…
Syntaxis
- .git / hooks / applypatch-msg
- .git / hooks / commit-msg
- .git / hooks / post-update
- .git / hooks / pre-applypatch
- .git / hooks / pre-commit
- .git / hooks / bereiden-commit-msg
- .git / hooks / pre-push
- .git / hooks / pre-rebase
- .git / hooks / bijwerken
Opmerkingen
--no-verify
of -n
om alle lokale hooks op het gegeven git commando over te slaan.
Bijv .: git commit -n
Informatie op deze pagina is verzameld van de officiële Git-documenten en Atlassian .
Commit-msg
Deze hook lijkt op de hook prepare-commit-msg
, maar wordt genoemd nadat de gebruiker een commit-bericht invoert in plaats van ervoor. Dit wordt meestal gebruikt om ontwikkelaars te waarschuwen als hun commit-bericht een onjuist formaat heeft.
Het enige argument dat aan deze haak wordt doorgegeven, is de naam van het bestand dat het bericht bevat. Als je het bericht dat de gebruiker heeft ingevoerd niet leuk vindt, kun je dit bestand ter plekke wijzigen (hetzelfde als prepare-commit-msg
) of je kunt de commit volledig afbreken door te verlaten met een niet-nul status.
Het volgende voorbeeld wordt gebruikt om te controleren of het woordticket gevolgd door een nummer aanwezig is in het commit-bericht
word="ticket [0-9]"
isPresent=$(grep -Eoh "$word" $1)
if [[ -z $isPresent ]]
then echo "Commit message KO, $word is missing"; exit 1;
else echo "Commit message OK"; exit 0;
fi
Lokale haken
Lokale hooks zijn alleen van invloed op de lokale repositories waarin ze zich bevinden. Elke ontwikkelaar kan zijn eigen lokale hooks wijzigen, zodat ze niet betrouwbaar kunnen worden gebruikt als een manier om een commit-beleid af te dwingen. Ze zijn ontworpen om het voor ontwikkelaars gemakkelijker te maken zich aan bepaalde richtlijnen te houden en potentiële problemen onderweg te voorkomen.
Er zijn zes soorten lokale hooks: pre-commit, prepare-commit-msg, commit-msg, post-commit, post-checkout en pre-rebase.
De eerste vier hooks hebben betrekking op commits en stellen je in staat om controle te hebben over elk onderdeel in de levenscyclus van een commit. Met de laatste twee kun je wat extra acties of veiligheidscontroles uitvoeren voor de git checkout en git rebase commando's.
Met alle "pre-" hooks kunt u de actie wijzigen die gaat plaatsvinden, terwijl de "post-" hooks voornamelijk worden gebruikt voor meldingen.
Post-checkout
Deze hook werkt op dezelfde manier als de post-commit
hook, maar deze wordt aangeroepen wanneer je een referentie met git checkout
. Dit kan een handig hulpmiddel zijn voor het opruimen van uw werkmap met automatisch gegenereerde bestanden die anders verwarring zouden veroorzaken.
Deze haak accepteert drie parameters:
- de ref van de vorige HEAD,
- de ref van de nieuwe HEAD, en
- een vlag die aangeeft of het een filiaalafrekening of een bestandsafrekening was (respectievelijk
1
of0
).
De exit status heeft geen invloed op het git checkout
commando.
Post-commit
Deze hook wordt direct na de commit-msg
hook aangeroepen. Het kan de uitkomst van de git commit
bewerking niet veranderen, daarom wordt het voornamelijk gebruikt voor kennisgevingsdoeleinden.
Het script heeft geen parameters en de exitstatus heeft op geen enkele manier invloed op de commit.
Post-ontvangen
Deze haak wordt genoemd na een succesvolle duwbewerking. Het wordt meestal gebruikt voor kennisgevingsdoeleinden.
Het script heeft geen parameters, maar pre-receive
dezelfde informatie als pre-receive
via standaardinvoer:
<old-value> <new-value> <ref-name>
Pre-commit
Deze hook wordt elke keer uitgevoerd als je git commit
uitvoert, om te verifiëren wat er gaat gebeuren. U kunt deze haak gebruiken om de momentopname te inspecteren die op het punt staat te worden vastgelegd.
Dit type hook is handig voor het uitvoeren van geautomatiseerde tests om ervoor te zorgen dat de inkomende commit de bestaande functionaliteit van uw project niet breekt. Dit type hook kan ook controleren op witruimte- of EOL-fouten.
Er worden geen argumenten doorgegeven aan het pre-commit script, en afsluiten met een niet-nul status breekt de hele commit af.
Bereid-commit-msg
Deze hook wordt genoemd naar de pre-commit
hook om de teksteditor te vullen met een commit-bericht. Dit wordt meestal gebruikt om de automatisch gegenereerde commit-berichten voor geplette of samengevoegde commits te wijzigen.
Een tot drie argumenten worden aan deze haak doorgegeven:
- De naam van een tijdelijk bestand dat het bericht bevat.
- Het type commit ook
- bericht (
-m
of-F
optie), - sjabloon (
-t
optie), - merge (als het een merge commit is), of
- squash (als het andere commits verplettert).
- bericht (
- De SHA1-hash van de betreffende commit. Dit wordt alleen gegeven als de optie
-c
,-C
of--amend
is opgegeven.
Net als bij pre-commit
, wordt bij het afsluiten met een niet-nulstatus de commit afgebroken.
Pre-rebase
Deze hook wordt aangeroepen voordat git rebase
begint te veranderen. Deze haak wordt meestal gebruikt om ervoor te zorgen dat een rebase-bewerking geschikt is.
Deze haak heeft 2 parameters:
- de stroomopwaartse tak waaruit de serie werd gevorkt, en
- de branch wordt rebased (leeg bij het rebasen van de huidige branch).
U kunt de rebase-bewerking afbreken door af te sluiten met een niet-nul status.
Pre-receive
Deze hook wordt elke keer uitgevoerd als iemand git push
gebruikt om commits naar de repository te pushen. Het bevindt zich altijd in de externe repository die de bestemming van de push is en niet in de oorspronkelijke (lokale) repository.
De hook wordt uitgevoerd voordat referenties worden bijgewerkt. Het wordt meestal gebruikt om elke vorm van ontwikkelingsbeleid af te dwingen.
Het script heeft geen parameters, maar elke ref die wordt gepusht, wordt doorgegeven aan het script op een aparte regel bij standaardinvoer in het volgende formaat:
<old-value> <new-value> <ref-name>
Bijwerken
Deze haak wordt genoemd naar pre-receive
en werkt op dezelfde manier. Het wordt aangeroepen voordat iets daadwerkelijk wordt bijgewerkt, maar wordt afzonderlijk aangeroepen voor elke ref die werd gepusht in plaats van alle refs tegelijk.
Deze haak accepteert de volgende 3 argumenten:
- naam van de ref die wordt bijgewerkt,
- oude objectnaam opgeslagen in de ref, en
- nieuwe objectnaam opgeslagen in de ref.
Dit is dezelfde informatie die wordt doorgegeven om pre-receive
, maar omdat update
voor elke ref afzonderlijk wordt aangeroepen, kunt u sommige refs afwijzen terwijl u andere toestaat.
Pre-push
Beschikbaar in Git 1.8.2 en hoger.
Pre-push haken kunnen worden gebruikt om te voorkomen dat een push gaat. Redenen waarom dit nuttig is, zijn onder meer: het blokkeren van onbedoelde handmatige pushs naar specifieke vertakkingen, of het blokkeren van pushs als een vastgestelde controle mislukt (unit tests, syntaxis).
Een pre-push hook wordt gemaakt door eenvoudig een bestand met de naam pre-push
onder .git/hooks/
, en ( gotcha alert ), en zorg ervoor dat het bestand uitvoerbaar is: chmod +x ./git/hooks/pre-push
.
Hier is een voorbeeld van Hannah Wolfe dat een push om te beheersen blokkeert:
#!/bin/bash
protected_branch='master'
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')
if [ $protected_branch = $current_branch ]
then
read -p "You're about to push master, is that what you intended? [y|n] " -n 1 -r < /dev/tty
echo
if echo $REPLY | grep -E '^[Yy]$' > /dev/null
then
exit 0 # push will execute
fi
exit 1 # push will not execute
else
exit 0 # push will execute
fi
Hier is een voorbeeld van Volkan Unsal dat ervoor zorgt dat RSpec-tests slagen voordat de push wordt toegestaan:
#!/usr/bin/env ruby
require 'pty'
html_path = "rspec_results.html"
begin
PTY.spawn( "rspec spec --format h > rspec_results.html" ) do |stdin, stdout, pid|
begin
stdin.each { |line| print line }
rescue Errno::EIO
end
end
rescue PTY::ChildExited
puts "Child process exit!"
end
# find out if there were any errors
html = open(html_path).read
examples = html.match(/(\d+) examples/)[0].to_i rescue 0
errors = html.match(/(\d+) errors/)[0].to_i rescue 0
if errors == 0 then
errors = html.match(/(\d+) failure/)[0].to_i rescue 0
end
pending = html.match(/(\d+) pending/)[0].to_i rescue 0
if errors.zero?
puts "0 failed! #{examples} run, #{pending} pending"
# HTML Output when tests ran successfully:
# puts "View spec results at #{File.expand_path(html_path)}"
sleep 1
exit 0
else
puts "\aCOMMIT FAILED!!"
puts "View your rspec results at #{File.expand_path(html_path)}"
puts
puts "#{errors} failed! #{examples} run, #{pending} pending"
# Open HTML Ooutput when tests failed
# `open #{html_path}`
exit 1
end
Zoals je kunt zien, zijn er veel mogelijkheden, maar het belangrijkste is om exit 0
te exit 0
als er goede dingen zijn gebeurd en exit 1
als er slechte dingen zijn gebeurd. Telkens wanneer je exit 1
de push voorkomen en heeft je code de status van voordat je git push...
uitvoert git push...
Houd er bij het gebruik van client-side hooks rekening mee dat gebruikers alle client-side hooks kunnen overslaan door de optie "--no-verifieer" te gebruiken bij een push. Als u op de haak vertrouwt om het proces af te dwingen, kunt u zich branden.
Documentatie: https://git-scm.com/docs/githooks#_pre_push
Officieel voorbeeld: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample
Controleer de Maven-build (of ander build-systeem) voordat u begint
.git/hooks/pre-commit
#!/bin/sh
if [ -s pom.xml ]; then
echo "Running mvn verify"
mvn clean verify
if [ $? -ne 0 ]; then
echo "Maven build failed"
exit 1
fi
fi
Bepaalde pushes automatisch doorsturen naar andere repositories
post-receive
hooks kunnen worden gebruikt om inkomende pushes automatisch door te sturen naar een andere repository.
$ cat .git/hooks/post-receive
#!/bin/bash
IFS=' '
while read local_ref local_sha remote_ref remote_sha
do
echo "$remote_ref" | egrep '^refs\/heads\/[A-Z]+-[0-9]+$' >/dev/null && {
ref=`echo $remote_ref | sed -e 's/^refs\/heads\///'`
echo Forwarding feature branch to other repository: $ref
git push -q --force other_repos $ref
}
done
In dit voorbeeld zoekt de egrep
regexp naar een specifiek vertakkingsformaat (hier: JIRA-12345 zoals gebruikt om Jira-problemen te benoemen). Je kunt dit onderdeel natuurlijk verlaten als je alle takken wilt doorsturen.