Hvad er Git-hooks, og hvordan bruges de?

Question

Accepted Answer

**Git-hooks** er scripts, som Git kører **automatisk** på bestemte punkter i Git-arbejdsgangen (før/efter commits, pushes, merges osv.). De muliggør automatisering — håndhævelse af standarder, kørsel af checks og udløsning af handlinger — og bruges bredt til kodekvalitet og CI-integration.

## Hvad hooks er

```text
Hooks are executable scripts in .git/hooks/ (or managed by tools) that Git runs on EVENTS:
  CLIENT-SIDE (local):
    pre-commit   → before a commit is created (lint, format, run quick tests)
    commit-msg   → validate/format the commit message
    pre-push     → before pushing (run tests, prevent pushing broken code)
    post-merge/checkout → after merge/checkout (e.g. reinstall dependencies)
  SERVER-SIDE (on the remote):
    pre-receive / update → enforce policies on push (reject bad pushes)
    post-receive → trigger deployment/CI/notifications after a push
```

## Almindelige anvendelser

```text
✓ pre-commit → LINT and FORMAT code; run quick tests; block secrets/debug code
  → catch issues BEFORE they're committed (fast feedback, consistent quality)
✓ commit-msg → enforce message format (e.g. Conventional Commits)
✓ pre-push → run the test suite → don't push failing code
✓ server-side → enforce policies; trigger CI/CD and deployments
```

## Styring af hooks i et team

```text
⚠️ .git/hooks/ is LOCAL and NOT committed → hooks aren't shared automatically.
To share hooks across a team, use tools:
  → HUSKY (JS ecosystem), pre-commit (Python framework), lefthook, etc.
  → these version hooks in the repo and install them for everyone
→ Combined with CI: hooks give FAST LOCAL feedback; CI is the enforced safety net
  (hooks can be bypassed with --no-verify, so CI must also enforce).
```

## Hvorfor det betyder noget

Forståelse af Git-hooks er værdifuld viden på seniorniveau for **automatisering af kvalitetscheck og arbejdsganghandlinger**, så det er nyttigt til at opretholde kodekvalitet og integration med CI/CD.

Hooks muliggør **automatisering ved vigtige Git-begivenheder** — kørsel af scripts automatisk før/efter commits, pushes, merges osv. — hvilket bruges bredt til at håndhæve standarder og fange problemer tidligt.

Den mest almindelige og værdifulde brug er **pre-commit-hooken** til at køre **linting, formatering, hurtige tests og hemmelighed-detektering før kode bliver committed** — hvilket giver hurtig feedback og sikrer konsistent kvalitet automatisk (så problemer fanges på commit-tidspunktet snarere end senere i CI eller review), en enormt populær praksis.

Andre anvendelser (commit-msg-hooks, der håndhæver beskedkonventioner som Conventional Commits, pre-push-hooks, der kører tests for at forhindre push af ødelagt kode, og server-side-hooks, der håndhæver politikker eller udløser CI/CD og deployments) udvider automatisering på tværs af arbejdsgangen.

Forståelse af det praktiske **team-styringaspekt** er vigtig: `.git/hooks/` er lokalt og **ikke committed**, så hooks deles ikke automatisk — deling af dem på tværs af et team kræver værktøjer som **Husky, pre-commit eller lefthook**, der versionerer hooks i repo'et og installerer dem for alle.

Krucielt er det at forstå, at hooks **kan omgås** (`--no-verify`), hvilket betyder, at de giver hurtig *lokal* feedback, men **CI skal også håndhæve** checksene som det rigtige sikkerhedsnet — en vigtig indsigt om forsvar i dybden (lokale hooks for hastighed, CI for håndhævelse).

Da automatisering af kvalitetscheck og arbejdsganghandlinger forbedrer kodekvalitet og konsistens, og da Git-hooks (især pre-commit for lokale check, styret via værktøjer og suppleret med CI) er en udbredt mekanisme til dette, er forståelse af Git-hooks — hvad de er, almindelige anvendelser, team-styring med værktøjer og deres forhold til CI — værdifuld viden på seniorniveau for at opbygge automatiserede, kvalitetsfokuserede udviklings-workflows, som afspejler de praksisser, der bruges til at opretholde kvalitet i faglige teams.