Git hooks i hverdagen: slik bruker du automatikk til å unngå kjedelige feil

Små feil som glemte formatteringer, manglende tester eller feil commit-meldinger stjeler tid og skaper støy i kodebasen. Ofte vet vi hva vibørgjøre før vi committer, men i en travel hverdag blir det ikke alltid gjort.

Git hooks lar deg automatisere nettopp disse tingene. Med noen få filer i repoet kan du få Git til å kjøre skript før eller etter commit, push og andre handlinger, uten ekstra verktøy eller avansert oppsett.

Hva er Git hooks, helt konkret?

Git hooks er små skript som Git automatisk kjører når bestemte hendelser skjer, for eksempel før en commit eller etter en merge. De ligger i prosjektet ditt og følger ofte repoet, så hele teamet kan få samme oppførsel.

Lokalt på maskinen din finnes det alltid en.git/hooks-mappe i hvert repo. Der legger Git inn eksempelfiler sompre-commit.sampleogpre-push.sample. Når du gir disse kjørbar rettighet og fjerner.sample, blir de faktiske hooks.

Hvorfor bry seg om Git hooks i det hele tatt?

Poenget er ikke å gjøre Git mer komplisert, men å fjerne manuelle rutiner som likevel bør skje hver gang. Typiske eksempler er å kjøre formattering, linting eller en smal test-suite automatisk før du committer.

Fordelen er at du flytter kontrollen nærmere koden. Feil blir fanget tidlig, og du unngår diskusjoner i pull requests om ting som kunne vært automatisert. Ulempen er at dårlige eller trege hooks kan irritere og bremse flyten, så balanse er viktig.

Typer hooks du faktisk har nytte av

Git har mange mulige hooks, men i vanlig utviklingsarbeid er det noen få som går igjen. Det er bedre å bruke to godt enn ti halvveis.

• pre-commit: Kjøres før Git lager en commit. Perfekt sted for format, lint og raske sjekker.
• commit-msg: Validerer commit-meldingen. Nyttig for konvensjoner som Conventional Commits eller interne regler.
• pre-push: Kjøres før endringer pushes til fjernrepo. Brukes ofte til å kjøre litt tyngre tester enn du vil ha i pre-commit.

Andre hooks sompost-mergeellerpost-checkoutkan også være nyttige, for eksempel til å installere avhengigheter eller generere filer når branchen endres, men start gjerne enkelt.

Kom i gang: din første pre-commit hook

La oss si at du vil sikre at all JavaScript/TypeScript-kode er formatert medPrettierog ateslintkjører på de filene du er i ferd med å committe. Poenget er det samme for andre språk og verktøy.

Gå inn i repoet ditt og åpne.git/hooks. Lag en ny fil kaltpre-commit(uten filtype), og legg inn noe ala dette for et Unix-miljø:

Eksempel på enkel pre-commit:

• Finn filene som er staged
• Filtrer på relevante endelser
• Kjør formattering og lint bare på disse

En enkel variant i Bash kan for eksempel hente alle staged filer medgit diff –cached –name-only, filtrere på.jsog.ts, og så kjøre et skript ipackage.jsonmed disse som argumenter. Etterpå må du kjørechmod +x .git/hooks/pre-commitfor at filen skal bli kjørbar.

Gjør hooks delbare med repoet

En vanlig felle er at hooks bare legges i.git/hooks. Denne mappen er ikke versjonert, så kollegaene dine får ikke samme oppsett. Da ender du med ulike regler lokalt og på CI.

En enkel løsning er å legge hook-skriptene i en mappe i repoet, for eksempel./githooks, og så peke Git dit. Du kan gjøre det med:

git config core.hooksPath githooks

Da vil Git bruke filene igithookssom hooks, og denne mappen kan versjoneres og sjekkes inn. Det gjør det lettere å holde oppsettet likt på tvers av maskiner og teammedlemmer.

Integrer NPM eller Yarn i hookene dine

I moderne JavaScript-prosjekter er det naturlig å la hooks kjøre vianpm scriptselleryarn-kommandoer. Det gjør at selve hook-filen kan være ganske tynn, og den faktiske logikken bor ipackage.json.

Typisk struktur kan være:

• Ipre-commit: kallnpm run precommiteller lignende.
• Ipackage.json: definer“precommit”: “lint-staged”eller et eget skript som kjører verktøyene du ønsker.

Fordelen er at det blir lett å kjøre de samme verktøyene manuelt, og CI kan bruke de samme skriptene. Husk at npm og yarn kan ha litt ulik oppførsel over tid, så det er lurt å sjekke dokumentasjonen for din versjon ved behov.

Vanlige feil og hvordan du unngår dem

Det er lett å gjøre hooks for tunge. Hvis pre-commit tar 20 sekunder, vil folk forsøke å hoppe over dem. La derfor tunge ting leve i CI eller i en pre-push hook, og hold pre-commit fokusert på raske kontroller.

En annen gjenganger er hooks som feiler på mystiske måter. Logg tydelig hva som skjer, og sørg for at skriptene avslutter med riktig exit-kode. 0 betyr suksess, alt annet stopper handlingen, for eksempel commit eller push.

Når Git hooks ikke er riktig verktøy

Hooks er lokale. De kan skrus av per maskin, og de kjører ikke på serveren din. De er derfor ikke et fullverdig alternativ til kvalitetssjekker i CI, men et supplement som hjelper deg å fange ting tidlig.

Hvis du trenger garantier på tvers av team og miljøer, må du kombinere hooks med regler i repoet, som beskyttede brancher med obligatoriske byggetrinn. Hooks er best egnet til den personlige arbeidsflyten og små kvalitetssikringer før koden forlater laptopen.

En enkel sjekkliste for gode Git hooks

Før du innfører eller endrer hooks i prosjektet ditt, kan det være nyttig å ta en kort runde på hva du faktisk vil oppnå. Her er en sjekkliste som kan brukes som utgangspunkt.

• Hva skal automatisk skje hver gang jeg committer eller pusher?
• Hvilke kontroller må være raske nok til ikke å irritere?
• Skal hookene deles via repoet medcore.hooksPath?
• Hvordan feiler skriptene, og gir de god, konkret feilmelding?
• Er tyngre sjekker flyttet til pre-push eller CI i stedet?

Med noen få velvalgte hooks får du en mer robust arbeidsflyt uten at det føles tungt. Start med én konkret forbedring, for eksempel format og lint ved pre-commit, og bygg gradvis videre når det fungerer godt i det daglige.