EMZETT.
Login

Emzett Wiki

Git-Hooks und pre-commit: Automatische Prüfungen vor dem Commit

Properties1
tagsglossar, git, qualitaet

2 Min. Lesezeit

Git-Hooks und pre-commit: Automatische Prüfungen vor dem Commit

Kurz: Git-Hooks führen Skripte bei bestimmten Ereignissen aus, etwa vor dem Commit; so lassen sich Formatierung, Linting, Tests und Secret-Scans automatisch erzwingen.

Genauer: Fehler früh zu finden spart Zeit. Git-Hooks sind Skripte im Ordner .git/hooks/, die Git bei Ereignissen startet: pre-commit, commit-msg, pre-push, post-merge u. a. Liefert ein Hook einen Fehlercode, bricht Git die Aktion ab.

Im Detail

Beispiel: eigener Hook

#!/bin/sh
# .git/hooks/pre-commit  (ausführbar machen: chmod +x)
npm run lint --silent || {
  echo "Lint-Fehler: Commit abgebrochen"; exit 1;
}

Problem: .git/hooks wird nicht versioniert und nicht mit dem Team geteilt. Besser: Hooks per Werkzeug verwalten, das sie aus dem Repository installiert.

Werkzeuge

  • pre-commit (Python-basiert, sprachunabhängig): Konfiguration in .pre-commit-config.yaml, Installation pre-commit install; Hooks für Black, Ruff, Prettier, ESLint, shellcheck, gitleaks, Trailing Whitespace u. v. m.
  • Husky + lint-staged (JavaScript): prüft nur geänderte Dateien.
  • Lefthook (schnell, Go).
  • In der Git-Konfiguration: git config core.hooksPath .githooks, wenn der Ordner im Repo liegt.
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.5.0
    hooks: [{id: ruff}, {id: ruff-format}]
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks: [{id: gitleaks}]

Was man prüfen lässt

  • Formatierung und Linting (schnell halten, damit niemand die Hooks umgeht).
  • Secrets (gitleaks) und große Dateien.
  • Commit-Nachrichten (commit-msg, Conventional Commits).
  • Schnelle Tests vor dem Push (pre-push).
  • Keine Merge-Konfliktmarker, keine console.log/debugger. Langsame Prüfungen (komplette Testsuite) gehören in die CI.

Grenzen

Hooks sind lokal und umgehbar (git commit --no-verify), also kein Ersatz für CI und Serverregeln (Branch Protection, Pflicht-Checks, Required Reviews). Sie sind ein Komfort, der Fehler früh sichtbar macht. Halte sie schnell (unter ein paar Sekunden), dokumentiere die Einrichtung im README und überprüfe sie in der CI nochmals.

Siehe auch: CI/CD-Pipeline, Conventional Commits, Secrets verwalten

Backlinks