Slik får du kontroll på Git hooks uten å skyte deg selv i foten

Git hooks kan gjøre arbeidsflyten din mye glattere: formatere kode automatisk, kjøre tester før commit og hindre at feil havner i hovedbranchen. Likevel er mange forsiktige med dem, fordi de kan føles magiske, skjøre og vanskelige å feilsøke.

I denne artikkelen ser vi praktisk på hvordan du setter opp, organiserer og vedlikeholder Git hooks slik at de hjelper deg i hverdagen i stedet for å stå i veien. Fokus ligger på enkle eksempler, konkrete filer og vanlige fallgruver.

Hva er Git hooks, egentlig?

Git hooks er skript som Git kjører automatisk ved bestemte hendelser, for eksempel før en commit, etter en merge eller når du gjør en push. Hver hook er en vanlig fil i et bestemt katalogmønster, som Git leter etter når noe skjer.

På hvert lokalt repository finnes en.git/hooks-mappe. Der ligger det ofte eksempelfiler med endelsen.sample. Disse brukes ikke før du gir dem riktig navn og kjørbarhet. Når en relevant hook-fil finnes og kan kjøres, kjører Git den automatisk.

Lokale hooks vs delte hooks i team

Som standard ligger hooks kun lokalt i.git/hooks. Det betyr at de ikke blir versjonert, og at kollegaene dine ikke får de samme sjekkene. For små soloprosjekter kan det være greit, men i et team gir det lett forskjellig oppførsel på hver maskin.

En vanlig løsning i team er å legge hooks i en versjonert mappe i prosjektet, for eksempel.githooks/, og så fortelle Git at denne mappen skal brukes. Da kan alle ha de samme reglene, og eventuelle endringer i hook-skript blir med i vanlige commits og pull requests.

Slik peker du Git til en egen hook-mappe

Du kan endre hvor Git leter etter hooks ved å settecore.hooksPath. Det kan gjøres på to nivåer: globalt for deg som utvikler, eller lokalt for ett enkelt prosjekt. For delte prosjektspesifikke hooks er det tryggest å gjøre dette lokalt i repoet.

Stå i rotmappen til prosjektet og kjør for eksempel:

git config core.hooksPath .githooks

Nå vil Git lete etter hook-filer i.githooks/i stedet for i.git/hooks/. Du kan sjekke at innstillingen er satt medgit config –get core.hooksPath. Husk å legge mappen og skriptene i versjonskontroll.

En enkel pre-commit hook som faktisk hjelper

Et klassisk bruksområde er å stoppe commits med åpenbart rot. Eksempel: blokkere commits som inneholderconsole.logi JavaScript ellervar_dumpi PHP. Da slipper du å huske på det manuelt ved hver commit.

Lag filen.githooks/pre-commitmed noe slikt innhold:

#!/usr/bin/env bash
set -e
if git diff –cached | grep -E “console.log|var_dump” >/dev/null; then
  echo “Commit avbrutt: fjern debug-utskrifter (console.log / var_dump).” >&2
  exit 1
fi

Gjør filen kjørbar, for eksempel medchmod +x .githooks/pre-commit. Neste gang du prøver å commite med slike strenger i staged filer, vil hooken stoppe deg med en tydelig beskjed.

Hvordan strukturere flere hooks uten kaos

Etter hvert vil du ofte ha flere ting som skal skje på samme hook, for eksempel både kodeformattering og en lett test. I stedet for å fylle én lang og uoversiktlig fil, kan du organisere det i mindre skript som kalles fra hooken.

En enkel løsning er å ha enscripts/-mappe i prosjektet ditt med små, navngitte skript somlint-staged.sh,run-tests.shellercheck-branch-name.sh. Hook-filene i.githooks/blir da kun tynne innpakninger som kaller disse.

Eksempel på pre-push hook som kaller to interne skript:

#!/usr/bin/env bash
set -e
./scripts/run-tests.sh
./scripts/check-branch-name.sh

Fordelen er at du kan gjenbruke skriptene i CI, manuelt i terminalen og fra hooks, uten å duplisere logikk mange steder.

Vanlige feil som gjør Git hooks irriterende

Det er noen klassiske feller som ofte gjør hooks mer plagsomme enn nyttige. Heldigvis er de enkle å unngå når du vet om dem. Første felle er manglende kjørbarhet på filene. Utenchmod +xkjører ikke hooken, selv om innholdet er riktig.

En annen typisk feil er å skrive hook-skript som tar veldig lang tid, for eksempel full systemtest ved hver commit. Slike hooks blir fort slått av av frustrerte utviklere. Prøv heller å kjøre lette sjekker lokalt, og la tyngre ting kjøre i byggserveren.

Til slutt er det mange som glemmer å logge tydelig hva som skjer når en hook stopper en operasjon. Uten god feilmelding føles det bare som at Git er tregt eller ustabilt. Skriv alltid forklarende tekst til stderr når du feiler, slik at det er lett å forstå hva som må fikses.

Slik feilsøker du når en hook blokkerer deg

Når en hook hindrer commit eller push, vil Git som regel vise exit-kode og eventuell tekst fra skriptet. Start med å lese denne nøye. Om det ikke er tydelig nok, åpne selve hook-filen og se hva den gjør, eller legg inn ekstraecho-linjer for midlertidig logging.

Du kan også kjøre hook-skriptet manuelt i terminalen for å se full output, for eksempel.githooks/pre-commit. Hvis du vil hoppe over hooks for en enkelt operasjon, kan du gjøre det bevisst, for eksempelgit commit –no-verify. Det bør likevel brukes med måte og helst kun når du vet hva du ignorerer.

Delte hooks i team: regler som tåler virkeligheten

I team er det lurt å starte forsiktig og kun innføre hooks som alle opplever som nyttige. Typiske kandidater er automatisk formattering eller lett linting på kun endrede filer, og enkle blokkerere for å hindre åpenbare feil som glemte secrets i commit.

Dokumenter alltid hvilke hooks som finnes og hva de gjør, gjerne i prosjektets README. Det gjør det enklere for nye utviklere å forstå oppsettet og feilsøke når noe stopper dem. Kombiner dette med eksempler på hvordan man kjører de samme sjekkene manuelt utenfor hookene.

Hvis det er stor variasjon i maskiner og operativsystemer, forsøk å holde hooks så enkle som mulig og unngå verktøy som ikke er lett tilgjengelige på alle plattformer. Alternativet er å kapsle alt inn via pakkehåndterere i prosjektet, for eksempel npm-skript eller tilsvarende.

Oppsummert: små scripts, stor gevinst

Git hooks kan spare deg for overraskelser i produksjon, unødige code reviews og tid brukt på å rette banale feil. Nøkkelen er å holde dem små, transparente og delte, slik at alle vet hva som skjer og kan stole på at skriptene gjør det de skal.

Start med én enkel pre-commit hook som løser et konkret problem du har i dag. Når den sitter og fungerer for alle, kan du gradvis bygge videre. På den måten får du et Git-miljø som hjelper deg, i stedet for et sett skjulte feller som bare lager frustrasjon.