Git Hooks – Komplette Anleitung: Installation, Nutzung und Tipps

Mit Git-Hooks kannst du Aufgaben in deinem Arbeitsablauf automatisieren, indem du Skripte vor oder nach Git-Aktionen wie Commits oder Pushes ausführst. Sie helfen dabei, Probleme frühzeitig zu erkennen, Standards durchzusetzen und sogar Probleme automatisch zu beheben.

Nehmen wir mal an, du hast ein Skript geschrieben, um die Stilstandards für Code durchzusetzen. Du kannst dieses Skript zu einem Hook hinzufügen, der vor einem Commit ausgeführt wird. Jetzt wird der Hook jedes Mal ausgeführt, wenn jemand versucht, einen Commit durchzuführen. Wenn der Code die Prüfungen im Hook besteht, wird der Commit durchgeführt. Wenn das nicht klappt, wird der Commit blockiert.

Und es geht nicht nur darum, Probleme zu melden. Du kannst das Skript auch anpassen, um diese Probleme zu beheben, bevor der Commit passiert. In diesem Artikel erkläre ich dir alles, was du über Git-Hooks wissen musst: Was sie sind, welche wichtig sind und wie du sie effektiv einsetzt.

Was sind Git-Hooks?

Git-Hooks starten automatisch benutzerdefinierte Skripte, wenn bestimmte Git-Aktionen, wie zum Beispiel vor oder nach einem Commit, Push oder Merge. Sie sind mit Git, sodass keine externen Bibliotheken installiert werden müssen.

Wenn du ein Git-Repository startest, erstellt Git standardmäßig die Hooks. Du findest sie im Verzeichnis „ .git/hooks “. Die kommen mit „ .sample “-Erweiterungen, die verhindern, dass sie standardmäßig laufen. Wenn du möchtest, dass sie standardmäßig ausgeführt werden, entferne einfach die Erweiterung „ .sample “.

Du kannst die Hooks in jeder ausführbaren Skriptsprache schreiben. Du kannst zum Beispiel in der Pre-Commit-Hook-Datei ein Skript einfügen, das nach „To-do”-Kommentaren in gestuften Dateien sucht und den Commit blockiert, wenn es welche findet. Das heißt, jedes Mal, wenn du versuchst, etwas zu committen, sucht Git nach Kommentaren, die mit „To-do“ anfangen, und schlägt fehl, wenn noch offene Aufgaben da sind. So kannst du benutzerdefinierte Hooks für verschiedene Git-Aktionen wie Post-Commit, Pre-Merge, Pre-Push und mehr erstellen.

Arten von Git-Hooks

Bevor wir uns mit praktischen Beispielen beschäftigen, schauen wir uns mal die beiden Arten von Git-Hooks an. 

Clientseitige Hooks: Kategorien und gängige Beispiele

Clientseitige Hooks laufen auf lokalen Rechnern während Git-Operationen wie Commits, Rebasing und Pushen. Hier sind ein paar beliebte Client-Hooks und ihre spezifischen Anwendungsfälle.

• Vorab-Verpflichtung: Läuft, bevor du überhaupt die Commit-Nachricht eingibst. Du kannst es nutzen, um Code-Stile durchzusetzen, Tests zu machen oder vor dem Commit auf Syntaxfehler zu checken. 
• commit-msg vorbereiten: Wird ausgeführt, nachdem Git die Standard-Commit-Meldung erstellt hat, aber bevor der Editor für die Commit-Meldung angezeigt wird. Dieser Hook kann die Standardmeldung anhand einer benutzerdefinierten Skriptlogik ändern oder ersetzen. 
• commit-msg: Dieser Hook wird direkt nach dem Speichern der Commit-Nachricht ausgeführt, aber bevor Git den Commit abschließt. Das ist dein letzter Check, um Regeln für Commit-Meldungen wie Formatierung, Struktur oder Tagging durchzusetzen.
• Nach dem Commit: Wird nach dem Erstellen eines Commits ausgeführt. Es wird oft für Benachrichtigungen (wie das Senden einer Slack-Nachricht nach einem Commit) oder für die Protokollierung (Speichern von Commit-Metadaten) verwendet.
• post-checkout: Wird nach einem erfolgreichen Befehl „ git checkout “ ausgeführt. Es startet, wenn du den Zweig wechselst oder einen bestimmten Commit oder Pfad auscheckst. Du kannst es nutzen, um Projektabhängigkeiten neu aufzubauen, temporäre Dateien zu löschen oder über einen neuen Zweig zu informieren.
• Nach der Zusammenführung: Läuft nach einer erfolgreichen Zusammenführung. Es wird oft benutzt, um Abhängigkeiten zu aktualisieren, Merge-Meldungen zu drucken oder Caches zu löschen.
• vor dem Rebase: Wird vor einem Rebase-Vorgang ausgeführt. Du kannst es nutzen, um das Rebasing geschützter Branches zu verhindern, Tests vor dem Rebasing durchzuführen oder ein Rebasing zu stoppen, wenn es nicht festgeschriebene Änderungen gibt.
• vor dem Push: Läuft, bevor Änderungen übernommen werden. Es hilft dabei, Pushes zu geschützten Branches zu verhindern oder Tests vor dem Push durchzuführen.
• Nach der Überarbeitung: Wird ausgeführt, nachdem Git die Commits erfolgreich umgeschrieben hat. Es wird bei Vorgängen wie „ git commit --amend “ (das den letzten Commit umschreibt) oder „ git rebase “ (das eine Reihe von Commits umschreibt) ausgelöst. Benutz es, um Referenzen zu aktualisieren oder Tests und CI-Schritte nach dem Umschreiben auszulösen.
• Vorab-Patch anwenden: Dieser Hook wird durch den Befehl „ git am “ gestartet und läuft, nachdem ein Patch auf den Arbeitsbaum angewendet wurde, aber bevor ein neuer Commit erstellt wird. Wenn die Prüfungen in diesem Hook nicht klappen, kann er mit einem Status ungleich Null beendet werden und verhindern, dass der Patch übernommen wird.
• Nach dem Patchen: Git macht das, nachdem der Patch angewendet und der Commit erstellt wurde. Es kann den Commit nicht abbrechen, eignet sich aber gut für die Protokollierung oder das Versenden von Benachrichtigungen.
• applypatch-msg: Git macht das, bevor „ git am “ den Patch anwendet. Benutz das, um die vorgeschlagene Commit-Nachricht für den Patch zu checken oder zu bearbeiten.

Server-seitige Hooks: Kategorien und Anwendungsfälle

Server-seitige Hooks laufen auf Remote-Git-Servern und werden ausgelöst, wenn Remote-Ereignisse passieren, wie zum Beispiel vor oder nach dem Pushen in ein Repository.

• vor dem Empfang: Die Fernbedienung macht das, bevor sie einen Push akzeptiert. Du kannst es nutzen, um einen einheitlichen Code-Stil für alle Benutzer durchzusetzen oder Sicherheitsprüfungen durchzuführen, bevor du Änderungen von einem Kunden akzeptierst.
• Update: Während „pre-receive“ bei jedem Push einmal läuft, wird der Update-Hook für jede Referenz (Zweig oder Tag) ausgeführt, die bei einem einzelnen Push geändert wird.
• nach dem Empfang: Wird nach dem Git-Push-Vorgang ausgeführt. Es wird oft benutzt, um Benachrichtigungen zu verschicken, alles zu protokollieren oder CI/CD-Pipelines zu starten.
• Nach dem Update: Wird ausgeführt, nachdem Git alle Referenzen in einem Push aktualisiert hat. Du kannst es für einfache Benachrichtigungen nutzen, weil es im Gegensatz zu „post-receive“ nicht auf die alten und neuen Protokolle jeder Referenzaktualisierung zugreifen kann.
• Referenztransaktion: Es wird ausgelöst, wenn eine Referenztransaktion vorbereitet, bestätigt oder abgebrochen wird, sodass es mehrmals laufen kann. Benutz es, um Updates über mehrere Referenzen in einer einzigen Transaktion zu bestätigen oder abzulehnen oder um Referenzänderungen zu protokollieren und zu überprüfen.
• Zur Kasse gehen: Löst aus, wenn du einen Git-Push zu einem Branch machst, der gerade auf dem Remote ausgecheckt ist. Mit diesem Hook kannst du Dateien auf dem Server nach einem Push aktualisieren, die Änderungen protokollieren oder unsichere Pushes direkt in das Arbeitsverzeichnis blockieren.
• vor der automatischen Garbage Collection: Läuft kurz bevor Git die automatische Garbage Collection startet. Du kannst es nutzen, um den Start der Garbage Collection zu protokollieren, sie während ressourcenintensiver Vorgänge zu blockieren oder alle notwendigen Aufgaben vor der Garbage Collection zu erledigen.
• proc-receive: Wird ausgeführt, wenn der Befehl „git-receive-pack“ einen eingehenden Push verarbeitet. Es aktualisiert Referenzen (Zweige und Tags) im Remote-Repository und meldet die Ergebnisse an den Client zurück.

Git-Hooks einrichten

Hier findest du die Schritte zum Installieren und Einrichten der Git-Hooks. Du wirst auch sehen, wie du eigene Hooks von Grund auf neu erstellen kannst. 

Installation und Konfiguration

Wenn du ein Git-Repository startest, legt Git automatisch ein paar Hooks im Ordner „ .git/hooks “ an. Um sie zu sehen, öffne dein Terminal und geh zum Stammverzeichnis des Repositorys, wo du „ git init “ ausgeführt hast. Öffne dann das versteckte Verzeichnis „ .git “ und dann das Unterverzeichnis „hooks“. Ein einfacher Befehl „ cd “ erledigt das alles für dich und gibt dir Zugriff auf das Unterverzeichnis „hooks“.

cd .git/hooks

Sobald du drin bist, siehst du die Standard-Hooks mit der Erweiterung „ .sample “. Um einen Standard-Hook zu aktivieren, lösch die Erweiterung „ .sample “ für diesen Hook und mach ihn ausführbar.

Verwende zum Beispiel den folgenden Befehl, um die Erweiterung „ .sample “ aus dem Pre-Commit-Hook zu entfernen.

mv .git/hooks/pre-commit.sample .git/hooks/pre-commit

Mach es dann mit dem folgenden Befehl ausführbar:

chmod +x .git/hooks/pre-commit

Das umfasst das Bearbeiten und Aktivieren der Standard-Hooks. Um eigene Hooks von Grund auf neu zu erstellen, machst du Folgendes.

Um eine neue Datei in „ .git/hooks/ “ zu öffnen, mach Folgendes:

nano .git/hooks/commit-msg

Mach das Skript in dieser Datei. Beispiel:

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

Speicher und beende das Programm, dann mach es ausführbar:

chmod +x .git/hooks/commit-msg 

Im obigen Beispiel geben die Hooks bei jedem Commit eine Meldung aus. " Commit message hook triggered"

Es gibt noch eine andere Möglichkeit, benutzerdefinierte Hooks einzurichten. Wenn du ein Repository startest, hat Git schon ein paar Standard-Hooks dabei. Du kannst diese Standardeinstellungen über Vorlagenverzeichnisse ändern. 

So läuft's ab: Wenn du „ git init “ ausführst, kopiert Git den Inhalt des globalen Vorlagenverzeichnisses in das Verzeichnis „ .git/ “ des neuen Repositorys, einschließlich der Hooks. Wenn du benutzerdefinierte Hook-Skripte zum globalen Vorlagenverzeichnis hinzufügst, werden diese benutzerdefinierten Hooks automatisch von jedem neuen Repository übernommen, das du erstellst.

Hook-Skripte erstellen und anpassen

Zuerst musst du dir überlegen, was du erreichen willst. Fängt es vage Commit-Meldungen ab, verhindert es versehentliche Pushes oder löscht es Caches? Es ist wichtig, das Ziel im Voraus festzulegen, weil verschiedene Git-Hooks unterschiedliche Zwecke erfüllen und du wissen solltest, welchen du verwenden musst. 

Wenn du zum Beispiel den Stil der Commit-Meldung checken willst, benutzt du den Hook „commit-msg“. Wenn du bestimmte Pushes zum Hauptzweig vermeiden willst, solltest du das mit einem Pre-Push-Hook machen. 

Sobald du den Aufhänger ausgewählt hast, musst du dich als Nächstes für die Sprache entscheiden. Unter macOS und Linux reicht oft ein kleines Bash-Skript (oder einfaches sh-Skript) aus. Unter Windows setzen manche Teams auf PowerShell. 

Wenn dein Repo polyglott ist, solltest du vielleicht einen universellen Interpreter wie Python oder Node.js nehmen, damit alle die gleiche Logik ausführen können. Deshalb ist es wichtig, oben einen Shebang (#!/bin/sh, #!/usr/bin/env python3 usw.) einzufügen, damit Git weiß, wie es das Skript ausführen soll.

Ein einfaches Beispiel für einen Pre-Commit-Hook, der verhindert, dass Dateien v .env -Dateien committet werden. So vermeidest du, dass du aus Versehen sensible API-Schlüssel weitergibst.

#!/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 0

Wenn du Hooks deaktivieren willst, ist es am einfachsten, sie vorübergehend umzubenennen (änder pre-commit in pre-commit.off) oder ihre Ausführungsberechtigung zu entfernen. 

Wenn du es aber nur einmal umgehen musst, benutze „ git commit --no-verify “, um Commit-Hooks zu überspringen, und „ git push --no-verify “, um Push-Hooks zu überspringen. Du kannst Hooks sogar komplett deaktivieren, indem du Git mit ` git config core.hooksPath /dev/null` auf einen leeren Ordner verweist.

Git Hooks – Häufige Anwendungsfälle und Beispiele

Git-Hooks sind echt praktisch, um Tests, Sicherheitschecks und die Einhaltung von Qualitätsstandards in deinem Arbeitsablauf automatisch zu machen. 

Praktische Automatisierungsszenarien

Code-Stil oder Linting durchsetzen: Der Pre-Commit-Hook wird oft benutzt, um die Codeformatierung zu automatisieren und mögliche Fehler zu erkennen, bevor der Commit durchgeführt wird.

Zum Beispiel kümmert sich prettier im folgenden Pre-Commit-Hook automatisch um die Formatierung und bereitet die Änderungen vor dem Commit vor. Ein Linter kann dann direkt danach laufen, und der Commit klappt nur, wenn der Linting erfolgreich ist. Wenn das nicht klappt, wird der Commit abgebrochen.

#!/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 0

Automatisierte Tests ausführen: Du kannst die Hooks so einstellen, dass automatisierte Tests laufen, bevor du irgendwelche Änderungen hochlädst. Der folgende Pre-Push-Hook findet zum Beispiel automatisch alle verfügbaren Pytests in deinem Repo und führt sie aus, bevor die Änderungen gepusht werden.

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

Sensible Daten automatisch blockieren: Heikle Dateien wie .env, .pem oder .key haben oft geheime Infos drin. Das folgende Beispiel für einen Pre-Commit-Hook sucht nach solchen Mustern und stoppt den Commit, wenn er sie enthält.

#!/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
}

Tipps zum Schreiben von effektiven Git-Hooks

Hier sind ein paar Tipps, die ich beim Schreiben von Git-Hooks als nützlich empfunden habe. 

Haken festhalten

Hooks werden jedes Mal ausgeführt, wenn du bestimmte Git-Aktionen startest, also halte sie möglichst einfach. Wenn du große Testsuiten hast, führe sie für eine bessere Leistung in CI statt in lokalen Hooks aus. Wenn du bei jedem Commit Linter, Formatierer oder Prüfungen im ganzen Repository laufen lässt, wird das deine Arbeit verlangsamen. Beschränk die Prüfungen also auf die Dateien, die sich tatsächlich geändert haben.

Plattformübergreifende Kompatibilität sicherstellen 

Stell sicher, dass deine Hooks auf verschiedenen Betriebssystemen reibungslos funktionieren. Benutz portable Shebangs, geh einheitlich mit Zeilenenden um (benutz LF statt CRLF) und schreib keine absoluten Pfade fest. 

Verlass dich stattdessen auf PATH und lokale Projektskripte wie npm run lint oder python -m, damit es in verschiedenen Umgebungen läuft.

Fehlerbehebungsstrategien

Füge ausführliche Protokollierung oder ein Debug-Flag hinzu (z. B. „ HOOK_DEBUG=1 “), um zu verfolgen, wie das Skript läuft. Druckt Details wie das aktuelle Verzeichnis, den aktuellen Zweig oder die Dateien, die bereitgestellt werden. Das macht es einfacher, den Ablauf zu verfolgen und zu erkennen, wo es Probleme gibt.

Probier mal verschiedene Eingaben aus und schau, ob alles klappt, bevor du die Änderungen veröffentlichst. Wenn ein Hook den Fortschritt unerwartet blockiert, kannst du ihn vorübergehend mit dem Git-Flag „ --no-verify “ oder mit Umgebungsvariablen umgehen, die dafür gemacht sind, Hooks zu überspringen.

Um ein einheitliches Verhalten über verschiedene Betriebssysteme hinweg zu gewährleisten, solltest du betriebssystemspezifische Befehle vermeiden und stattdessen portable Skriptsprachen bevorzugen.

Dokumente klar einhängen

Gute Dokumentation hilft dem Team, sich besser zu verstehen, und macht es einfacher, neue Leute einzubinden. Erstell eine zentrale README-Datei, in der der Zweck, das Verhalten und die Verwendung jedes Hooks genau beschrieben werden. Schreib rein, wie man es ausführt, was man vorher machen muss, wie man Probleme löst und wie man sie umgeht. Gib auch Anweisungen für die Installation/Einrichtung dazu. 

Fortgeschrittene Implementierungstechniken und Best Practices für Git-Hooks

Wenn du ein fortgeschrittener Nutzer bist, können dir diese Tipps helfen:

Leistungsoptimierung

Um die Leistung in komplizierten Arbeitsabläufen zu verbessern, solltest du externe Abhängigkeiten reduzieren, indem du große Bibliotheken vermeidest. Das verkürzt die Startzeit und reduziert Fehlerquellen. 

Speichere die Ergebnisse von aufwendigen Prozessen wie Linting im Cache, damit du sie wiederverwenden kannst, wenn sich die Dateien nicht geändert haben. 

Wenn Hooks mehrere Prüfungen haben, mach sie parallel, damit sie gleichzeitig laufen. Modularisiere auch Hook-Skripte. Das heißt, Struktur-Hooks sind kleine, wiederverwendbare Teile, die nur die relevanten Teile je nach Kontext ausführen.

Hook-Verkettung und Orchestrierung

Benutze Hook-Verkettung, um mehrere Hooks in einem einzigen Git-Ereignis auszuführen. In einem Pre-Commit-Hook könntest du zum Beispiel erst Linting machen, dann Tests laufen lassen und schließlich den Code formatieren – alles hintereinander. Jeder Befehl wird nacheinander ausgeführt. Wenn einer davon schiefgeht (mit einem Status ungleich Null beendet wird), können die folgenden Befehle übersprungen werden, um einen fehlerhaften Commit zu vermeiden. 

Wenn die Hook-Aktionen unabhängig voneinander sind, kannst du sie auch parallel ausführen, um Zeit zu sparen. Hier setzt man Orchestrierung ein, um die Ausführung von Aufgaben in der richtigen Reihenfolge zu verwalten.

Konfigurationsmanagement 

Jedes Repo hat sein eigenes Verzeichnis „ .git/hooks “. Das heißt, wenn du in mehreren Projekten die gleichen Checks (z. B. Linting) haben willst, musst du sie überall kopieren und einfügen. Besser ist es, Hooks zentral zu verwalten, damit alle Repositorys drauf zugreifen und sie ausführen können.

Das kannst du mit einem einzigen Befehl machen: git config --global core.hooksPath ~/.githooks. Das sagt Git, dass es im Ordner „ ~/.githooks “ nach Hooks suchen soll. Alle Hooks, die du dort erstellst, werden automatisch für alle deine Repositorys freigegeben.

Du kannst die Hook-Logik auch mit Konfigurationsdateien (JSON oder YAML) dynamischer gestalten. Anstatt für jedes Repository eine eigene Logik festzuprogrammieren, kann dein Hook-Skript die Konfigurationsdatei des Repositorys lesen und automatisch die richtigen Regeln anwenden.

Bedingte Ausführung

In den Hook-Skripten kannst du einfache Bedingungen hinzufügen, damit sie nur dann ausgeführt werden, wenn sie relevant sind. Das könnte bedeuten, den aktuellen Zweignamen zu checken, zu schauen, welche Dateien tatsächlich geändert wurden, oder eine Umgebungsvariable zu lesen, die ihnen sagt, dass sie überspringen sollen.

Wenn du mehr Kontrolle haben willst, nimm ein Framework wie pre-commit, wo du in einer Konfigurationsdatei festlegst, welche Hooks in welcher Phase laufen sollen. Du kannst auch bedingte Logik hinzufügen, z. B. Hooks nur auf bestimmten Branches ausführen, Hooks mit Variablen überspringen oder sogar zeitbasierte Bedingungen hinzufügen. Dadurch werden deine Hook-Skripte dynamisch und auf echte Arbeitsabläufe zugeschnitten.

Zusammenarbeit und Strategien zum Teilen 

Es gibt zwei Möglichkeiten, wie du Git-Hooks zentralisieren und für verschiedene Repositorys und Teams freigeben kannst:

Git-Vorlagen

Wenn du ein Repository startest, legt Git ein paar Standard-Hooks im Verzeichnis „ git/hooks “ an. Die kommen aus der Standardvorlage von Git.

Um benutzerdefinierte Hooks zentral zu erstellen, kannst du ein Git-Vorlagenverzeichnis anlegen, deine Hooks dort schreiben und Git global so einstellen, dass dieses neue Verzeichnis als Standardvorlage verwendet wird. 

git config --global init.templateDir /path/to/hooks-template

Aber bei dieser Methode fehlt die Versionskontrolle für die Hooks. Das ist besonders praktisch, wenn du deine Hooks nur selten änderst. Wenn du Hooks oft aktualisierst und Versionskontrolle brauchst, solltest du lieber die nächste Methode verwenden.

Zentrales Git-Repository

Mach dir ein eigenes, versionskontrolliertes, zentrales Repository und speicher alle deine benutzerdefinierten Hook-Skripte dort, getrennt von den Projekt-Repos. Du kannst also die Hooks unabhängig vom Projekt-Codebasis aktualisieren. 

Diese Hooks sollten standardisiert sein, also vermeide fest codierte Pfade oder Werte, die an ein einzelnes Repository gebunden sind.

Diese Einrichtung ist besonders praktisch für Teams, weil jeder regelmäßig Updates holen und mit seinen Projekten synchronisieren kann. 

Effizienter ist es, ein Setup-Skript zu verwenden, das das zentrale Hooks-Repo klont und die Hook-Skripte in das Verzeichnis „ .git/hooks “ jedes Projekts kopiert. Beispiel für ein Setup-Skript: 

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

# Location of the shared hooks template repo
HOOKS_TEMPLATE_REPO="git@github.com: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"

Eine andere Möglichkeit ist, Symlinks zu benutzen. Du kannst das Verzeichnis „ .git/hooks “ jedes Projekts mit den Skripten in deinem versionskontrollierten Hooks-Repo verknüpfen. Wenn du also das zentrale Repo aktualisierst, werden die Hooks automatisch mitaktualisiert, weil der Symlink darauf zeigt.

Damit das System zuverlässig bleibt, solltest du einen klaren Prozess für die Wartung der Hooks einrichten. Teammitglieder sollten Änderungen an Hooks mit Pull-Anfragen vorschlagen, erst nach Überprüfung zusammenführen und die Dokumentation bei Weiterentwicklungen der Hooks auf dem neuesten Stand halten. 

Git-Hooks in Entwicklungs-Workflows einbauen

Git-Hooks sind echt wichtig für die kontinuierliche Integration (CI). Nur zur Info: CI heißt, dass man Änderungen oft zusammenführt und dann Builds und Tests durchführt, um Probleme frühzeitig zu erkennen. Wenn du Hooks mit CI/CD-Tools wie Jenkins, GitHub Actions oder GitLab CI verbindest, kannst du Builds starten, Tests laufen lassen und sogar Anwendungen automatisch basierend auf Git-Ereignissen bereitstellen.

Ein server-seitiger Pre-Receive-Hook führt zum Beispiel ein benutzerdefiniertes Skript auf dem Git-Server aus, bevor er einen Push akzeptiert. Wenn das Skript nicht klappt, lehnt der Server den Push ab. Damit kannst du checken, ob der neueste CI-Build auf diesem Branch erfolgreich war, bevor du den Push freigibst. Dieser CI-Lauf kann Codeabdeckungsprüfungen, Unit- oder Integrationstests oder sogar Sicherheitsscans beinhalten.

Hooks können auch Deployment-Aufgaben automatisch erledigen. Ein Post-Receive-Hook kann einen Webhook auslösen, der eine CI/CD-Pipeline startet. Wenn Code in den Hauptzweig integriert wird, startet automatisch der Zyklus aus Erstellen → Bereitstellen → Veröffentlichen.

Sicherheitsüberlegungen und bewährte Vorgehensweisen 

Wenn du zentrale Hooks für eine einfachere Zusammenarbeit und gemeinsame Informationen verwaltest, solltest du sicherstellen, dass das Hooks-Verzeichnis sichere Dateiberechtigungen hat, um unbefugten Zugriff zu verhindern. Nur vertrauenswürdige Leute sollten Schreibzugriff haben. 

Du musst immer die Eingaben oder Parameter überprüfen, die deine Hook-Skripte bekommen, um Code-Injection-Angriffe zu vermeiden. Überprüfe zum Beispiel Eingaben anhand strenger Muster, wie zum Beispiel nur Zweignamen mit Buchstaben, Zahlen und Bindestrichen zuzulassen oder Tags, die mit vMAJOR.MINOR.PATCH übereinstimmen. 

Schreib sensible Daten niemals fest in Hook-Skripten. Verwende stattdessen Umgebungsvariablen oder spezielle Tools zur Verwaltung geheimer Daten, um Anmeldedaten während der Laufzeit sicher bereitzustellen. Du kannst Tools wie Gitleaks mit Pre-Commit-Hooks verbinden, um Sicherheitsscans für sensible Infos in den Änderungen durchzuführen, die du gerade committen willst.

Jemand kann deinen Hook umleiten, um den Code oder die Infos an einen anderen Server zu schicken. Also schränke ein, welche Domänen deine Hooks erreichen können. Benutz einen Proxy oder eine Firewall, um unbekannte Zielserver zu blockieren. Stell außerdem sicher, dass deine Protokolle keine vertraulichen Infos in den angezeigten Meldungen zeigen. 

Fazit

Git-Hooks sind ein super Tool, um Aufgaben zu automatisieren und Standards direkt in deinem Entwicklungs-Workflow durchzusetzen. Sie helfen bei allem, vom Code-Stil und Testen bis hin zur Bereitstellung und Sicherheitsüberprüfung.

Wenn du sie richtig einsetzt, kannst du Fehler vermeiden, Zeit sparen und die Zusammenarbeit zwischen den Teams verbessern.

Fang mit einfachen Pre-Commit-Checks an und probier dann fortgeschrittenere Sachen wie Orchestrierung, zentrales Management oder CI/CD-Integrationen aus. Wenn du Git benutzt und deine Kenntnisse verbessern willst, schau dir diesen Fortgeschrittenenkurs zu Gitan.