Git Hooks Complete Guide: installatie, gebruik en tips

Met Git-hooks kun je taken in je workflow automatiseren door scripts uit te voeren vóór of na Git-acties zoals commits of pushes. Ze helpen om problemen vroeg te signaleren, standaarden af te dwingen en zelfs automatisch issues te verhelpen.

Stel, je hebt een script geschreven om codestijl-standaarden af te dwingen. Je kunt dat script koppelen aan een hook die vóór een commit draait. Vanaf dat moment wordt de hook elke keer uitgevoerd als iemand probeert te committen. Als de code door de checks van de hook komt, gaat de commit door. Zo niet, dan wordt de commit geblokkeerd.

En het gaat niet alleen om het signaleren van problemen. Je kunt het script ook zo aanpassen dat het die issues oplost vóórdat de commit plaatsvindt. In dit artikel bespreek ik alles wat je moet weten over Git-hooks: wat het zijn, welke belangrijk zijn en hoe je ze effectief implementeert.

Wat zijn Git-hooks?

Git-hooks voeren automatisch aangepaste scripts uit wanneer bepaalde Git-acties plaatsvinden, zoals vóór of na een commit, push of merge. Ze zijn ingebouwd in Git, dus je hoeft geen externe libraries te installeren.

Wanneer je een Git-repository initialiseert, maakt Git de hooks standaard aan. Je vindt ze in de map .git/hooks. Ze hebben een .sample-extensie, waardoor ze standaard niet worden uitgevoerd. Als je wilt dat ze meteen draaien, verwijder je gewoon de .sample-extensie.

Je kunt de hooks schrijven in elke uitvoerbare scripttaal. Zo kun je in het pre-commit hook-bestand een script toevoegen dat zoekt naar "To-do"-comments in gestagede bestanden en de commit blokkeert als die worden gevonden. Dat betekent dat Git elke keer dat je wilt committen, zoekt naar comments die beginnen met “To-do” en faalt als er nog open taken zijn. Op deze manier kun je aangepaste hooks maken voor diverse git-acties zoals post-commit, pre-merge, pre-push en meer.

Typen Git-hooks

Voordat we in praktische voorbeelden duiken, is het goed om de twee typen Git-hooks te begrijpen. 

Client-side hooks: categorieën en veelvoorkomende voorbeelden

Client-side hooks draaien op lokale machines tijdens Git-bewerkingen zoals committen, rebasen en pushen. Hier zijn een paar populaire client-hooks en hun specifieke use-cases.

• pre-commit: Draait nog vóórdat je de commitboodschap typt. Je kunt hem gebruiken om codestijlen af te dwingen, tests te draaien of op syntaxfouten te controleren voordat je commit. 
• prepare-commit-msg: Draait nadat Git de standaard commitboodschap heeft aangemaakt, maar vóórdat de commit message-editor opent. Deze hook kan de standaardboodschap aanpassen of vervangen op basis van je scriptlogica. 
• commit-msg: Deze hook draait direct nadat de commitboodschap is opgeslagen, maar vóórdat Git de commit afrondt. Het is je laatste controlepunt om regels voor commitboodschappen af te dwingen, zoals opmaak, structuur of tagging.
• post-commit: Draait nadat een commit is aangemaakt. Wordt vaak gebruikt voor notificaties (zoals een Slack-bericht na een commit) of logging (commitmetadata opslaan).
• post-checkout: Draait na een geslaagd git checkout-commando. Hij wordt getriggerd wanneer je van branch wisselt of een specifieke commit of pad checkt. Je kunt hem gebruiken om dependencies opnieuw op te bouwen, tijdelijke bestanden te verwijderen of te melden dat er een nieuwe branch is.
• post-merge: Draait na een geslaagde merge. Wordt vaak gebruikt voor het updaten van dependencies, het printen van mergeberichten of het legen van caches.
• pre-rebase: Draait vóór een rebase. Je kunt hem gebruiken om rebasen van beschermde branches te voorkomen, tests te draaien voordat de rebase wordt toegestaan, of een rebase te stoppen als er on-gecommitte wijzigingen zijn.
• pre-push: Draait vóór het pushen van wijzigingen. Helpt om pushes naar beschermde branches te voorkomen of om pre-push tests te draaien.
• post-rewrite: Draait nadat Git commits succesvol heeft herschreven. Wordt getriggerd door bewerkingen zoals git commit --amend (die de laatste commit herschrijft) of git rebase (die een reeks commits herschrijft). Gebruik hem om referenties bij te werken of tests en CI-stappen te triggeren na herschrijven.
• pre-applypatch: Aangeroepen door het git am-commando; deze hook draait nadat een patch is toegepast op de working tree, maar vóórdat een nieuwe commit wordt gemaakt. Als de checks falen, kan hij met een niet-nulstatus stoppen en voorkomen dat de patch wordt gecommit.
• post-applypatch: Git draait deze na het toepassen van de patch en het aanmaken van de commit. Hij kan de commit niet afbreken, maar werkt goed voor logging of notificaties.
• applypatch-msg: Git draait deze vóórdat git am de patch toepast. Gebruik hem om de voorgestelde commitboodschap voor de patch te controleren of te bewerken.

Server-side hooks: categorieën en use-cases

Server-side hooks draaien op externe Git-servers en worden getriggerd wanneer er remote events plaatsvinden, zoals vóór of na het pushen naar een repository.

• pre-receive: De remote draait deze voordat een push wordt geaccepteerd. Je kunt hiermee een consistente codestijl afdwingen voor alle gebruikers of securitychecks uitvoeren voordat wijzigingen van een client worden geaccepteerd.
• update: Waar pre-receive één keer per push draait, draait de update-hook voor elke referentie (branch of tag) die in één push wordt gewijzigd.
• post-receive: Draait nadat de git push-operatie is voltooid. Wordt vaak gebruikt voor het versturen van notificaties, uitgebreide logging of het triggeren van CI/CD-pijplijnen.
• post-update: Draait nadat Git alle referenties in een push heeft bijgewerkt. Je kunt hem gebruiken voor eenvoudige notificaties omdat hij, in tegenstelling tot post-receive, niet bij zowel de oude als nieuwe logs van elke referentie-update kan.
• reference-transaction: Wordt geactiveerd wanneer een referentie-transactie wordt voorbereid, gecommit of afgebroken, en kan dus meerdere keren draaien. Gebruik hem om updates over meerdere referenties in één transactie te valideren of te weigeren, of om ref-wijzigingen te loggen en te auditen.
• push-to-checkout: Triggert wanneer je git push naar een branch die momenteel is uitgecheckt op de remote. Met deze hook kun je na een push bestanden op de server bijwerken, wijzigingen loggen of onveilige pushes direct naar de working directory blokkeren.
• pre-auto-gc: Draait vlak voordat Git automatische garbage collection uitvoert. Je kunt hem gebruiken om de start van garbage collection te loggen, deze te blokkeren tijdens resource-intensieve operaties, of om voorbereidende taken af te handelen.
• proc-receive: Draait wanneer het git-receive-pack-commando een inkomende push verwerkt. Het werkt referenties (branches en tags) bij in de remote repository en rapporteert de resultaten terug aan de client.

Git-hooks instellen

In dit onderdeel vind je de stappen om de git-hooks te installeren en in te stellen. Je ziet ook hoe je vanaf nul aangepaste hooks maakt. 

Installatie- en configuratiemechanismen

Wanneer je een Git-repository initialiseert, maakt Git automatisch een set hooks aan in de map .git/hooks. Om ze te bekijken, open je je terminal en ga je naar de root van de repository waar je git init hebt uitgevoerd. Open daar de verborgen map .git en vervolgens de submap hooks. Een eenvoudige cd-opdracht doet dit allemaal voor je en geeft toegang tot de hooks-submap.

cd .git/hooksMogelijk gemaakt door

Eenmaal binnen zie je standaard hooks met de extensie .sample. Om een standaardhook te activeren, verwijder je de .sample-extensie voor die hook en maak je hem uitvoerbaar.

Gebruik bijvoorbeeld onderstaand commando om de .sample-extensie van de pre-commit hook te verwijderen.

mv .git/hooks/pre-commit.sample .git/hooks/pre-commitMogelijk gemaakt door

Maak hem daarna uitvoerbaar met het volgende commando:

chmod +x .git/hooks/pre-commitMogelijk gemaakt door

Dat dekt het bewerken en activeren van de standaardhooks. Volg deze stappen om vanaf nul aangepaste hooks te maken.

Om een nieuw bestand te openen in .git/hooks/, voer je uit:

nano .git/hooks/commit-msgMogelijk gemaakt door

Schrijf het script in dit bestand. Voorbeeld:

 #!/bin/sh
echo "✅ Commit message hook triggered"Mogelijk gemaakt door

Sla op en sluit af, maak het vervolgens uitvoerbaar:

chmod +x .git/hooks/commit-msg Mogelijk gemaakt door

In het bovenstaande voorbeeld printen de hooks een bericht " Commit message hook triggered" telkens wanneer de commit doorgaat.

Er is nog een manier om aangepaste hooks in te stellen. Wanneer je een repository initialiseert, bevat Git standaard hooks. Je kunt deze standaarden bewerken met templatemappen. 

Zo werkt het: wanneer je git init uitvoert, kopieert Git de inhoud van de globale templatemap naar de .git/-map van de nieuwe repository, inclusief hooks. Als je aangepaste hook-scripts toevoegt aan de globale templatemap, erft elke nieuwe repository die je maakt deze hooks automatisch.

Hook-scripts maken en aanpassen

Bepaal eerst wat je wilt bereiken. Wil je vage commitboodschappen tegenhouden, per ongeluk pushen voorkomen of caches legen? Het doel vooraf definiëren is belangrijk, omdat verschillende git-hooks verschillende doelen dienen en je moet weten welke je gebruikt. 

Wil je bijvoorbeeld de stijl van de commitboodschap controleren, dan gebruik je de commit-msg hook. Wil je bepaalde pushes naar de main-branch vermijden, doe dat dan met een pre-push hook. 

Als je de hook hebt gekozen, is de volgende beslissing de taal. Op macOS en Linux is een kleine Bash- (of plain sh-)script vaak voldoende. Op Windows leunen sommige teams op PowerShell. 

Als je repo polyglot is, heb je misschien liever een universele interpreter zoals Python of Node.js, zodat iedereen dezelfde logica kan draaien. Belangrijk is dan om een shebang (#!/bin/sh, #!/usr/bin/env python3, etc.) bovenaan op te nemen zodat Git weet hoe het script uit te voeren.

Een eenvoudig pre-commit hook-voorbeeld dat het committen van .env-bestanden voorkomt. Dit voorkomt dat je per ongeluk gevoelige API-sleutels pusht.

#!/bin/sh

# Block committing secrets
if git diff --cached --name-only | grep -q ".env"; then
  echo "❌ .env file detected in commit! Remove it before committing."
  exit 1
fi

exit 0Mogelijk gemaakt door

Als je hooks wilt uitschakelen, is de eenvoudigste manier om ze tijdelijk te hernoemen (verander pre-commit naar pre-commit.off) of hun uitvoerrechten te verwijderen. 

Maar als je ze slechts één keer wilt omzeilen, gebruik dan git commit --no-verify om commit-hooks over te slaan en git push --no-verify om push-hooks over te slaan. Je kunt hooks zelfs globaal uitschakelen door Git naar een lege map te laten wijzen met git config core.hooksPath /dev/null.

Veelvoorkomende use-cases en voorbeelden voor Git-hooks

Git-hooks zijn vooral handig voor het automatiseren van tests, securitychecks en het afdwingen van kwaliteitsstandaarden in je workflow. 

Praktische automatiseringsscenario’s

Codestijl of linting afdwingen: de pre-commit hook wordt vaak gebruikt om code automatisch te formatteren en potentiële fouten te onderscheppen voordat de commit doorgaat.

In de volgende pre-commit hook regelt prettier bijvoorbeeld automatisch de formatting en worden de wijzigingen vóór het committen opnieuw gestaged. Een linter kan daarna direct draaien, en de commit slaagt alleen als de linting slaagt. Zo niet, dan wordt de commit gestopt.

#!/bin/sh

# Collect staged JS/TS files
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts|tsx)$')
[ -z "$FILES" ] && exit 0

echo "Formatting with Prettier..."
npx --yes prettier --write $FILES

# Re-stage files that Prettier changed
echo "$FILES" | xargs git add

echo "Linting with ESLint..."
npx --yes eslint $FILES
STATUS=$?

if [ $STATUS -ne 0 ]; then
  echo "ESLint found issues. Fix them or commit with --no-verify if needed."
  exit $STATUS
fi

echo "Pre-commit checks passed."
exit 0Mogelijk gemaakt door

Automatisch tests uitvoeren: Je kunt hooks zo instellen dat ze geautomatiseerde tests draaien vóórdat er iets gepusht wordt. In het volgende pre-push hook-voorbeeld worden automatisch beschikbare pytests in je repo ontdekt en uitgevoerd vóór de push.

#!/bin/sh
echo "Running tests before push..."
pytest -q
STATUS=$?
[ $STATUS -eq 0 ] || { echo "Tests failed. Push aborted."; exit $STATUS;Mogelijk gemaakt door

Automatisch het committen van gevoelige data blokkeren: Gevoelige bestanden zoals .env, .pem of .key bevatten vaak secrets. Het volgende pre-commit hook-voorbeeld controleert op zulke patronen en blokkeert de commit als ze voorkomen.

#!/bin/sh
set -e

STAGED=$(git diff --cached --name-only --diff-filter=ACM)

# Block dotenv and private keys
echo "$STAGED" | grep -E '\.env(\.|$)|(^|/)\.env$|\.pem$|\.key$|id_rsa$' >/dev/null 2>&1 && {
  echo "Sensitive file detected in staged changes. Remove it from the commit."
  exit 1
}Mogelijk gemaakt door

Tips voor het schrijven van effectieve Git-hooks

Hieronder vind je enkele tips die ik handig vind bij het schrijven van Git-hooks. 

Houd hooks snel

Hooks draaien elke keer dat je bepaalde Git-acties uitvoert, dus houd ze lichtgewicht. Als je grote test-suites hebt, draai die dan in CI in plaats van in lokale hooks voor betere performance. Linters, formatters of checks over de hele repository op elke commit laten draaien vertraagt je, dus beperk checks tot daadwerkelijk gewijzigde bestanden.

Behoud cross-platform compatibiliteit 

Zorg dat je hooks soepel werken op verschillende besturingssystemen. Gebruik draagbare shebangs, ga consistent om met regeleinden (gebruik LF in plaats van CRLF) en hardcode geen absolute paden. 

Verlaat je in plaats daarvan op PATH en lokale projectscripts zoals npm run lint of python -m, zodat het in meerdere omgevingen draait.

Debugstrategieën

Voeg uitgebreide logging of een debugflag toe (bijvoorbeeld HOOK_DEBUG=1) om te volgen hoe het script draait. Print details zoals de huidige map, branch of gestagede bestanden. Dit maakt het makkelijker om de uitvoerstroom te volgen en te zien waar het misgaat.

Test hooks met verschillende inputs en simuleer lokale failures voordat je wijzigingen pusht. Als een hook onverwacht blokkeert, kun je hem tijdelijk omzeilen met Git’s --no-verify-flag of met omgevingsvariabelen die zijn ontworpen om hooks over te slaan.

Om consistent gedrag over besturingssystemen te behouden, vermijd OS-specifieke commando’s en kies bij voorkeur draagbare scripttalen.

Documenteer hooks duidelijk

Goede documentatie verbetert het begrip binnen het team en maakt onboarding van nieuwe leden makkelijker. Onderhoud een centrale README met het doel, gedrag en gebruik van elke hook. Voeg toe hoe je ze draait, vereisten, troubleshooting en tips om te omzeilen. Voorzie ook installatie-/setupinstructies. 

Geavanceerde implementatietechnieken en best practices voor Git-hooks

Als je een meer gevorderde gebruiker bent, kunnen deze tips helpen:

Prestatie-optimalisatie

Om performance te optimaliseren in complexe workflows, verminder externe afhankelijkheden door zware libraries te vermijden. Dit verkort de opstarttijd en vermindert faalpunten. 

Cache de resultaten van dure processen zoals linting, zodat je ze kunt hergebruiken wanneer bestanden niet zijn gewijzigd. 

Als hooks meerdere checks bevatten, voer ze dan parallel uit zodat ze gelijktijdig draaien. Moduleer hook-scripts ook: structureer hooks als herbruikbare, kleine componenten die alleen relevante onderdelen uitvoeren op basis van context.

Hook-chaining en orkestratie

Gebruik hook-chaining om meerdere hooks te draaien bij één git-event. In een pre-commit hook wil je bijvoorbeeld eerst linten, dan tests draaien en vervolgens code formatteren, allemaal aan elkaar geketend. Elke opdracht draait na elkaar en als er één faalt (niet-nulstatus), kunnen volgende opdrachten worden overgeslagen om een slechte commit te voorkomen. 

Als de hook-acties onafhankelijk zijn, kun je ze ook parallel draaien om tijd te besparen. Dan gebruik je orkestratie om de taken in de juiste volgorde te beheren.

Configuratiebeheer 

Elke repo heeft zijn eigen .git/hooks-map. Dat betekent dat je, als je dezelfde checks (bijv. linting) in meerdere projecten wilt, ze overal moet copy-pasten. Beter is om hooks centraal te beheren zodat alle repositories ze kunnen gebruiken en draaien.

Dat kan met één commando:  git config --global core.hooksPath ~/.githooks. Dit vertelt Git om hooks te zoeken in de map ~/.githooks. Alle hooks die je daar maakt, worden automatisch gedeeld over al je repositories.

Je kunt hooklogica ook dynamischer maken met configbestanden (JSON of YAML). In plaats van verschillende logica hard te coderen per repository, kan je hook-script het configbestand van die repository lezen en automatisch de juiste regels toepassen.

Voorwaardelijke uitvoering

Binnen de hook-scripts kun je eenvoudige voorwaarden toevoegen zodat ze alleen draaien wanneer relevant. Dat kan betekenen: de huidige branchnaam controleren, kijken welke bestanden daadwerkelijk zijn gewijzigd of een omgevingsvariabele lezen die aangeeft dat ze moeten overslaan.

Wil je meer controle, gebruik dan een framework zoals pre-commit, waarin je in een configbestand aangeeft welke hooks in welke fase draaien. Je kunt ook conditionele logica toevoegen, zoals hooks alleen op bepaalde branches draaien, hooks overslaan met variabelen of zelfs tijdgebaseerde voorwaarden toevoegen. Zo worden je hook-scripts dynamisch en afgestemd op echte workflows.

Samenwerking en delingsstrategieën 

Er zijn twee manieren om git-hooks te centraliseren en te delen over repositories en teams:

Git-templates

Wanneer je een repository initialiseert, voegt Git enkele standaardhooks toe onder de map git/hooks. Deze komen uit Git’s standaardtemplate.

Om centraal aangepaste hooks te maken, kun je een Git-templatemap aanmaken, je hooks daarin schrijven en Git globaal instellen om deze nieuwe map als standaardtemplate te gebruiken. 

git config --global init.templateDir /path/to/hooks-templateMogelijk gemaakt door

Maar deze methode mist versiebeheer voor de hooks. Dit is vooral handig als je hooks zelden veranderen. Als je hooks vaak bijwerkt en versiebeheer nodig hebt, gebruik je beter de volgende methode.

Centrale git-repo

Maak een aparte, versiebeheer-de, centrale repository en sla al je aangepaste hook-scripts op in die repo, los van projectrepo’s. Zo kun je updates aan de hooks onafhankelijk van de projectcodebase doorvoeren. 

Deze hooks moeten gestandaardiseerd zijn, dus vermijd het hardcoden van paden of waarden die aan één repository zijn gebonden.

Deze setup is vooral handig voor teams, omdat iedereen regelmatig updates kan binnenhalen en ze synchroniseren met hun projecten. 

Een efficiëntere aanpak is een setupscript dat de centrale hooks-repo clonet en de hook-scripts kopieert naar de map .git/hooks van elk project. Voorbeeldsetupscript: 

#!/usr/bin/env bash
set -euo pipefail

# Location of the shared hooks template repo
HOOKS_TEMPLATE_REPO="[email protected]:your-org/git-hooks-template.git"
HOOKS_TEMPLATE_DIR="$HOME/.git-hooks-template"

# Clone or update the template repo
 echo "Cloning hooks template repo..."
 git clone "$HOOKS_TEMPLATE_REPO" "$HOOKS_TEMPLATE_DIR"

# The repo where you want hooks installed
TARGET_REPO="${1:-$(pwd)}"
TARGET_HOOKS_DIR="$TARGET_REPO/.git/hooks"

# --- Copy strategy ---
echo "Copying hooks into $TARGET_HOOKS_DIR..."
cp -r "$HOOKS_TEMPLATE_DIR/"* "$TARGET_HOOKS_DIR/"

# 4. Make sure hooks are executable
chmod +x "$TARGET_HOOKS_DIR"/* || true

echo "✅ Hooks installed successfully into $TARGET_REPO"Mogelijk gemaakt door

Een andere optie is het gebruik van symlinks. Je kunt de map .git/hooks van elk project linken aan de scripts in je versiebeheer-de hooks-repo. Wanneer je de centrale repo bijwerkt, worden de hooks automatisch bijgewerkt omdat de symlink ernaartoe verwijst.

Om dit systeem betrouwbaar te houden, stel je een duidelijk proces in voor het beheren van hooks. Teamleden dienen hook-wijzigingen voor te stellen met pull requests, pas na review te mergen en de documentatie bij te houden naarmate hooks evolueren. 

Git-hooks integreren met ontwikkelworkflows

Git-hooks spelen een grote rol in continuous integration (CI). Ter context: CI betekent vaak veranderingen mergen en vervolgens builds en tests draaien om issues vroeg te vinden. Door hooks te koppelen aan CI/CD-tools zoals Jenkins, GitHub Actions of GitLab CI kun je builds triggeren, tests draaien en zelfs applicaties automatisch deployen op basis van Git-events.

Zo draait een server-side pre-receive hook een custom script op de Git-server voordat een push wordt geaccepteerd. Als het script faalt, weigert de server de push. Je kunt dit gebruiken om te controleren of de laatste CI-build op die branch geslaagd is voordat de push wordt toegestaan. Die CI-run kan onder meer code coverage-checks, unit- of integratietests of zelfs securityscans bevatten.

Hooks kunnen ook deploymenttaken automatiseren. Een post-receive hook kan een webhook triggeren die een CI/CD-pijplijn start. Wanneer code in main wordt gemerged, start automatisch de cyclus build → deploy → release.

Beveiligingsoverwegingen en best practices 

Als je centrale hooks onderhoudt voor makkelijke samenwerking en een gedeelde bron van waarheid, zorg dan dat de hookmap veilige bestandsrechten heeft om ongeautoriseerde toegang te voorkomen. Alleen vertrouwde gebruikers mogen schrijfrechten hebben. 

Valideer altijd de inputs of parameters die je hook-scripts ontvangen om code-injectieaanvallen te voorkomen. Valideer inputs bijvoorbeeld met strikte patronen, zoals alleen branchnamen met alfanumerieke tekens en streepjes toestaan, of tags die overeenkomen met vMAJOR.MINOR.PATCH. 

Hardcode nooit gevoelige data in hook-scripts. Gebruik in plaats daarvan omgevingsvariabelen of speciale secret management-tools om credentials veilig op runtime aan te leveren. Je kunt tools zoals Gitleaks integreren met pre-commit hooks om securityscans uit te voeren op gevoelige informatie in de wijzigingen die je op het punt staat te committen.

Iemand kan je hook omleiden om de code of informatie naar een andere server te sturen. Beperk daarom welke domeinen je hooks mogen bereiken. Gebruik een proxy of firewall om onbekende bestemmingsservers te blokkeren. Zorg er ook voor dat je logs geen vertrouwelijke info tonen in de weergegeven berichten. 

Conclusie

Git-hooks zijn een krachtige manier om taken te automatiseren en standaarden af te dwingen direct in je ontwikkelworkflow. Ze helpen bij alles van codestijl en testen tot deployment en securitychecks.

Door ze goed te gebruiken, verminder je fouten, bespaar je tijd en verloopt samenwerking tussen teams soepeler.

Begin met eenvoudige pre-commitchecks en experimenteer daarna met geavanceerdere setups zoals orkestratie, centraal beheer of CI/CD-integraties. Ben je een Git-gebruiker en wil je je skills uitbreiden, bekijk dan deze gevorderde Git-cursus.