Die Grundlagen von Git Hooks: Eine Fibel<\/h2>\n
Eine der wichtigsten Funktionen von Git<\/a> sind seine Hooks: ein leistungsf\u00e4higer Mechanismus, mit dem du Aufgaben automatisieren, Standards durchsetzen und konsistente Arbeitsabl\u00e4ufe \u00fcber den gesamten Lebenszyklus eines Projekts hinweg sicherstellen kannst.<\/p>\n Git-Hooks sind Skripte, die automatisch an bestimmten Punkten im Git-Workflow ausgef\u00fchrt werden. Du kannst sie verwenden, um das Verhalten von Git an die Bed\u00fcrfnisse deines Projekts anzupassen und zu erweitern. Hooks sorgen daf\u00fcr, dass die Qualit\u00e4t des Codes erhalten bleibt, Tests durchgef\u00fchrt und Verteilungen reibungslos organisiert werden.<\/p>\n Git bietet verschiedene Arten von Hooks, die jeweils in unterschiedlichen Phasen des Git-Workflows ausgel\u00f6st werden k\u00f6nnen:<\/p>\n Du findest die Hooks im Verzeichnis Hooks werden bei verschiedenen Git-Aktionen ausgel\u00f6st. Ein Pre-Commit-Hook wird zum Beispiel ausgef\u00fchrt, wenn du \u00c4nderungen \u00fcbertr\u00e4gst, und ein Pre-Push-Hook wird ausgel\u00f6st, bevor du einen Push an eine andere Stelle sendest<\/a>. Sobald du mehr \u00fcber diese Ausl\u00f6ser wei\u00dft, kannst du Hooks strategisch einsetzen, um die Qualit\u00e4tskontrolle zu verbessern und deinen Arbeitsablauf zu optimieren.<\/p>\n Das Erstellen und Installieren von benutzerdefinierten Git-Hooks kann ein komplexer Prozess sein. Aber die Grundlagen, die du hier lernst, werden dich sp\u00e4ter bei der Entwicklung fortgeschrittener Hooks unterst\u00fctzen. Gehen wir ein paar Konzepte durch, die f\u00fcr jeden Hook gelten, den du erstellst und installierst.<\/p>\n Die Wahl des richtigen Hook-Typs f\u00fcr deinen speziellen Anwendungsfall ist ein wichtiger erster Schritt. Du kannst damit beginnen, indem du deinen eigenen Arbeitsablauf und deine Bed\u00fcrfnisse kennst. Hier ist eine kurze Checkliste mit \u00dcberlegungen zu diesem Thema:<\/p>\n An diesem Punkt solltest du in der Lage sein, klare Ziele f\u00fcr deinen Hook zu definieren. Es kann sogar sein, dass jedes Ziel eine andere Art von Hook erfordert. Es ist zwar verlockend, Skripte f\u00fcr alle m\u00f6glichen Szenarien zu erstellen, aber es ist eine gute Idee, sich zuerst auf die kritischen Punkte zu konzentrieren.<\/p>\n Die richtige Benennung und Platzierung von benutzerdefinierten Git Hooks ist entscheidend f\u00fcr ihre Funktionalit\u00e4t und Wartbarkeit. Wie die Funktionen, Dateien, Klassennamen und vieles mehr in deinem Code sollten auch deine Git Hooks eine einheitliche und aussagekr\u00e4ftige Namenskonvention haben.<\/p>\n Wenn die Hooks im Laufe der Zeit mehrere Projekte unterst\u00fctzen, solltest du Pr\u00e4fixe verwenden – vielleicht mit den Initialen des Entwicklers, einer Abteilung oder einem Firmennamen. In der Regel verwenden Git-Hooks Kleinbuchstaben und Bindestriche, um die Lesbarkeit zu verbessern – z. B. my-project-pre-commit<\/b>.<\/p>\n W\u00e4hrend du Git-Hooks im Verzeichnis .git\/hooks<\/b> deines Projektarchivs speichern kannst, sollten benutzerdefinierte<\/i> Hooks in einem separaten Verzeichnis im Stammverzeichnis des Projekts abgelegt werden. So verhinderst du, dass sie bei einem Git-Update versehentlich \u00fcberschrieben werden. Du solltest jedoch eine Versionskontrolle<\/a> f\u00fcr diese Hooks zusammen mit dem restlichen Code deines Projekts einrichten.<\/p>\n Um einen einfachen Git-Hook zu erstellen, legst du in der Regel eine neue Datei mit dem Namen des gew\u00fcnschten Hooks (z. B. pre-commit<\/b>) in deinem Hooks-Verzeichnis an. Wir werden die Hook-Namen sp\u00e4ter auflisten, wenn wir \u00fcber Parameter sprechen.<\/p>\n Bevor du eine Datei \u00f6ffnest, um mit ihr zu arbeiten, solltest du sicherstellen, dass sie mit dem folgenden Befehlszeilen-Snippet ausf\u00fchrbar ist:<\/p>\n Denk daran, unsere Platzhalter durch die richtigen Informationen zu ersetzen. Wir werden im Laufe des Beitrags immer wieder auf dieses Snippet verweisen, da es eine typische Aktion sein sollte, wenn du einen neuen Git-Hook erstellst.<\/p>\n Sobald die Datei ausf\u00fchrbar und ge\u00f6ffnet ist, f\u00fcgst du deine eigene Logik in deiner bevorzugten Skriptsprache hinzu. Das kann Bash, Python<\/a>, Ruby<\/a> oder eine andere sein. Die Erstellung solcher Skripte w\u00fcrde den Rahmen dieses Artikels sprengen. Sp\u00e4ter gibt es jedoch einige Pseudocode-Beispiele, um bestimmte Anwendungsf\u00e4lle und Szenarien zu veranschaulichen.<\/p>\n Bevor du \u00c4nderungen \u00fcbertr\u00e4gst, solltest du deinen Hook testen, indem du versuchst, die entsprechende Aktion (z. B. eine \u00dcbertragung) auszuf\u00fchren. Dies ist der grundlegende Ansatz f\u00fcr die Erstellung von Git-Hooks, aber es gibt auch viele fortgeschrittene Anwendungsf\u00e4lle. Darauf gehen wir als N\u00e4chstes ein.<\/p>\n Das Erstellen einfacher Git-Hooks wirst du im Laufe deiner Entwicklungskarriere h\u00e4ufig tun. Es gibt jedoch viele Situationen, in denen du fortgeschrittenere und komplexere Hooks brauchst. Im Folgenden sehen wir uns einige Anwendungsf\u00e4lle und Beispiel-Hooks f\u00fcr verschiedene g\u00e4ngige Szenarien an.<\/p>\n Die Verwendung eines Linters zur Durchsetzung von Code-Styling ist eine fantastische Anwendung f\u00fcr Git-Hooks. Er kann dazu beitragen, eine einheitliche Codequalit\u00e4t in deinem Repository aufrechtzuerhalten, und ist etwas, von dem du viel profitieren kannst.<\/p>\n Nat\u00fcrlich solltest du einen Linter w\u00e4hlen, der zu der Programmiersprache deines Projekts passt. Black<\/a> ist zum Beispiel fantastisch f\u00fcr Python. Wir werden hier ESLint<\/a> f\u00fcr JavaScript verwenden, um einen Pre-Commit-Hook zu erstellen.<\/p>\n Installiere zun\u00e4chst den Linter als globales oder lokales Paket in deinem Projekt. Daf\u00fcr brauchst du Node.js<\/a> und npm<\/a>:<\/p>\n Als N\u00e4chstes navigierst du zu deinem Hooks-Verzeichnis in deinem Repo. Erstelle deine Pre-Commit-Datei und schreibe dann ein Skript, das den Linter auf deine bereitgestellten Dateien anwendet. Der Hook sollte den Commit verhindern, wenn der Linter irgendwelche Probleme findet. Hier ist ein grobes Beispiel:<\/p>\n Sobald du sichergestellt hast, dass der Hook ausf\u00fchrbar ist, teste ihn mit einem Commit. Der Pre-Commit-Hook sollte den Linter ausf\u00fchren. Wenn es Verst\u00f6\u00dfe gegen den Code-Stil gibt, kannst du den Commit nicht abschlie\u00dfen, bis du die Probleme behoben hast.<\/p>\n Nat\u00fcrlich solltest du einen Hook schreiben, der mit deiner eigenen Programmiersprache<\/a> und deinem Linter funktioniert, je nach Projekt. Du k\u00f6nntest dieses Beispiel z. B. mit Linter-Konfigurationseinstellungen erweitern, es in deinen Build-Prozess integrieren und vieles mehr.<\/p>\n Die Implementierung eines Pre-Commit-Hooks zur Ausf\u00fchrung von Tests vor einem Commit ist eine hervorragende M\u00f6glichkeit, um potenzielle Probleme fr\u00fchzeitig zu erkennen. So kannst du sicherstellen, dass du nur zuverl\u00e4ssigen Code \u00fcbergibst.<\/p>\n F\u00fcr dieses Beispiel verwenden wir das Jest Testing Framework<\/a> f\u00fcr JavaScript. Du solltest (wie immer) etwas Passendes f\u00fcr dein Projekt installieren:<\/p>\n Wie bei jedem Hook navigierst du zu deinem Hooks-Verzeichnis, erstellst eine neue Datei, benennst sie und machst sie ausf\u00fchrbar. Von hier aus schreibst du ein Skript, das vor dem Commit Tests f\u00fcr alle bereitgestellten Dateien durchf\u00fchrt. Hier ist eine grobe Vorlage:<\/p>\n Wenn du versuchst, \u00c4nderungen zu \u00fcbertragen, f\u00fchrt der Hook deine Tests f\u00fcr die bereitgestellten Dateien aus. Bei fehlgeschlagenen Tests wird die \u00dcbertragung abgebrochen, und du solltest die Probleme beheben, bevor du die \u00dcbertragung erneut durchf\u00fchrst.<\/p>\n Eine hervorragende M\u00f6glichkeit, den Freigabeprozess zu rationalisieren, ist die Automatisierung der Versionskontrolle und des Taggings in Git. So stellst du eine konsistente Versionierung deiner gesamten Codebasis sicher.<\/p>\n W\u00e4hle zun\u00e4chst ein f\u00fcr dein Projekt geeignetes Versionsschema. Das w\u00fcrde den Rahmen dieses Artikels sprengen, aber g\u00e4ngige Schemata sind Semantic Versioning (SemVer) oder ein benutzerdefiniertes Versionierungsmuster.<\/p>\n Als N\u00e4chstes musst du entscheiden, was dein Hook genau tun soll. Er k\u00f6nnte zum Beispiel die aktuelle Version lesen, sie nach einem bestimmten Schema erh\u00f6hen und die notwendigen Dateien mit der neuen Version aktualisieren. Au\u00dferdem solltest du ein Skript schreiben, das auf Basis der Version Tags erstellt und Git-Befehle verwendet, um leichtgewichtige oder mit Anmerkungen versehene Tags zu erstellen.<\/p>\n Sobald du die Berechtigungen f\u00fcr deine Datei erstellt und festgelegt hast, kannst du damit beginnen, deinen Hook zu schreiben. Das kann ein komplexer und sehr spezifischer Hook sein, der sich sogar von Projekt zu Projekt \u00e4ndern kann. Die meisten Hooks dieser Art enthalten jedoch Folgendes:<\/p>\n Von hier aus sollte das Skript die Versionsdatei mit der neuen Nummer aktualisieren, ein leichtgewichtiges Tag mit der neuen Version erstellen und optional das neue Tag in ein entferntes Repository pushen. Sobald du die \u00c4nderungen \u00fcbertr\u00e4gst, sorgt der Hook daf\u00fcr, dass jede \u00dcbertragung mit der richtigen Version und dem richtigen Tag verkn\u00fcpft wird.<\/p>\n Du wirst diesen Hook wahrscheinlich noch weiter an die Anforderungen deines Projekts anpassen wollen. So k\u00f6nntest du z. B. die Erstellung der ersten Tags, den Umgang mit Versionskonflikten und die Aktualisierung von Versionsverweisen in Dateien \u00fcbernehmen.<\/p>\n Ein Grund, warum Git Hooks so leistungsf\u00e4hig sind, ist die Art und Weise, wie sie mit dynamischen Variablen umgehen. Das kann jedoch ein komplexes Konzept sein, das es zu verstehen gilt. Im Folgenden werden wir uns sowohl die Umgebungsvariablen als auch die Hook-Parameter ansehen – und mit letzteren beginnen.<\/p>\n Hooks k\u00f6nnen bestimmte Parameter von Git erhalten, um auf kontextbezogene Informationen aus deiner Hauptcodebasis zuzugreifen. Git setzt die Parameter zur Laufzeit automatisch, und obwohl du sie in den meisten F\u00e4llen nicht definieren musst, kann es sein, dass du sie angeben musst. Es ist wichtig, diese zu verstehen, um effektive Hooks zu entwickeln.<\/p>\n Hier ist ein \u00dcberblick \u00fcber die wichtigsten Parameter f\u00fcr Hooks:<\/p>\n Wenn du einen Parameter hinzuf\u00fcgst, den der Hook nicht aufrufen kann, kann das Skript ihn in der Regel nicht verwenden. Parameter sind spezifisch f\u00fcr einen bestimmten Hook und Ausf\u00fchrungskontext. Um Probleme zu vermeiden, solltest du nur dokumentierte Parameter verwenden. Du kannst<\/i> jedoch den Wert eines Positionsparameters einer anderen Variablen zuweisen und ihn dann in deinem Skript verwenden:<\/p>\n In diesem Fall hat die Variable Beachte, dass du in manchen F\u00e4llen die Standardeingabe ( Da jeder Git-Hook seine eigenen Parameter hat, brauchst du wahrscheinlich eine Referenz, um herauszufinden, welche Parameter f\u00fcr deine spezielle Anwendung gelten. Die gute Nachricht ist, dass es mehrere M\u00f6glichkeiten gibt, dies zu tun.<\/p>\n In der offiziellen Git-Hook-Dokumentation<\/a> findest du zum Beispiel einige der g\u00e4ngigsten Parameter. Am besten ist es jedoch, wenn du einen der Git-Hooks als Beispiel \u00f6ffnest. Diese bestehen aus einem Mini-Leitfaden, der dir zeigt, wie du den Hook skriptest und der auch die Parameterdefinitionen f\u00fcr dich enth\u00e4lt:<\/p>\n Sie eignen sich hervorragend, um sich mit Git-Hooks vertraut zu machen, und helfen dir vielleicht sogar dabei, sie zu kodieren.<\/p>\n Git-Hooks k\u00f6nnen Argumente aus der Befehlszeile und von Mit diesen Umgebungsvariablen<\/a> kannst du das Verhalten deiner Git-Hooks anpassen und Entscheidungen auf der Grundlage verschiedener Aspekte des Git-Workflows treffen. Auf diese Weise kannst du dynamische und kontextabh\u00e4ngige Git-Hooks erstellen. Du kannst sie zum Beispiel verwenden, um Commit-Nachrichten zu \u00fcberpr\u00fcfen, den Zugriff auf bestimmte Zweige zu kontrollieren oder benutzerdefinierte Aktionen auf der Grundlage der Identit\u00e4t des Autors auszul\u00f6sen.<\/p>\n Alle Umgebungsvariablen aufzulisten, w\u00fcrde den Rahmen dieses Beitrags sprengen. Wir empfehlen dir, die Git-Dokumentation<\/a> und die Beispiel-Hooks zu lesen, um herauszufinden, welche Variablen verwendet werden.<\/p>\n Git setzt normalerweise automatisch verschiedene Umgebungsvariablen, je nachdem, welchen Hook es aufruft. Das kann zu Problemen f\u00fchren, wenn du nicht wei\u00dft, was gesetzt wird. Nimm zum Beispiel das folgende Ergebnis f\u00fcr die Variable Zum Gl\u00fcck gibt es eine M\u00f6glichkeit zu testen, wie Git mit Umgebungsvariablen umgeht<\/a>, indem du ein kleines Snippet in deinem Hook verwendest:<\/p>\n Um den Code zusammenzufassen: Zeile zwei gibt das Skript aus, das gerade l\u00e4uft; Zeile drei zeigt alle Umgebungsvariablen an und filtert sie dann nach denen, die „GIT“ im Namen haben; Zeile vier gibt das aktuelle Arbeitsverzeichnis aus.<\/p>\n Sobald du das Skript ausf\u00fchrst, siehst du eine Ausgabe, die den Umgebungsvariablen entspricht, die mit deinem Hook verbunden sind. So kannst du sicherstellen, dass deine eigenen Git-Hooks die Umgebungsvariablen so nutzen k\u00f6nnen, wie du es m\u00f6chtest.<\/p>\n Die Verwaltung von Git Hooks in einem Team oder einer Organisation ist wichtig, um einheitliche Entwicklungspraktiken zu gew\u00e4hrleisten und deine Arbeitsabl\u00e4ufe<\/a> effizient zu automatisieren. Ein Beispiel daf\u00fcr ist die Zuweisung eines eigenen Hooks-Verzeichnisses. Hier gibt es zwei Ratschl\u00e4ge, die wir dir geben k\u00f6nnen:<\/p>\n Je wahrscheinlicher es ist, dass Hooks in mehreren Projekten eingesetzt werden, desto wichtiger ist die Dokumentation. Du solltest eine umfassende Dokumentation f\u00fchren, die den Zweck, die Verwendung und die Konfigurationsoptionen f\u00fcr jeden Hook im Repo beschreibt. Code-Reviews und Aktualisierungsstrategien f\u00fcr diese globalen Hooks sind ebenfalls wichtig.<\/p>\n Wir empfehlen dir au\u00dferdem, benutzerdefinierte Hooks zusammen mit der Codebasis deines Projekts im Versionskontrollsystem (VCS) zu speichern. So wird sichergestellt, dass das gesamte Team Zugriff auf die gesamte Bibliothek der Hooks hat.<\/p>\n Serverseitige Hooks werden auf dem Server ausgef\u00fchrt, der das zentrale Git Repo hostet. So kannst du Richtlinien durchsetzen, Pr\u00fcfungen durchf\u00fchren oder Aktionen auf der Serverseite ausl\u00f6sen.<\/p>\n Du hast zwei M\u00f6glichkeiten, deine serverseitigen Hooks zu speichern: innerhalb des VCS neben deinem Projekt oder in separaten Repositories.<\/p>\n Es hat zwei Vorteile, wenn du dein VCS zum Speichern von serverseitigen<\/a> Hooks verwendest. Erstens kannst du sicherstellen, dass die Hooks die gleiche Versionierung und Wartung haben wie der Rest deiner Codebasis. Zweitens musst du nur ein Repository klonen, um sowohl auf den Projektcode als auch auf die Hooks zuzugreifen.<\/p>\n Je nach Art der Hooks kann es jedoch zu Sicherheitsbedenken f\u00fchren, wenn die Hooks auf sensible Daten zugreifen, wenn sie im selben Repository gespeichert werden. Und wenn die Hooks komplex sind oder bestimmte Konfigurationen erfordern, kann dies die Komplexit\u00e4t deines Haupt-Repos erh\u00f6hen.<\/p>\n Wenn du serverseitige Hooks in separaten Repos aufbewahrst, kannst du sie unabh\u00e4ngig von deiner Codebasis aktualisieren und versionieren, was m\u00f6gliche Konflikte reduziert. Diese Modularit\u00e4t kann zu mehr Flexibilit\u00e4t f\u00fchren.<\/p>\n Au\u00dferdem kannst du diese Hooks in Repositories mit eingeschr\u00e4nktem Zugriff speichern. So kannst du das Risiko der Offenlegung sensibler Daten verringern.<\/p>\n Im Gegensatz dazu kann die Pflege mehrerer Repositories<\/a> zus\u00e4tzlichen Aufwand bedeuten. Wenn Hooks auf bestimmte Versionen deiner Hauptcodebasis angewiesen sind, kann es au\u00dferdem eine Herausforderung sein, \u00c4nderungen zwischen deinen Repos zu koordinieren.<\/p>\n Wenn du die Installation von Hooks in mehreren Repositories automatisierst, sparst du Zeit und sorgst f\u00fcr Konsistenz in deinem Entwicklungsworkflow. Mithilfe von Skripten und Vorlagen kannst du ganz einfach Hooks in verschiedenen Repositories einrichten, ohne manuell eingreifen zu m\u00fcssen.<\/p>\n Der Prozess beginnt mit einem speziellen Repository, das deine globalen Hooks enth\u00e4lt. Du solltest diese standardisieren: Vermeide es zum Beispiel, Pfade oder Werte speziell f\u00fcr ein einzelnes Repository zu kodieren.<\/p>\n Von hier aus kannst du beginnen, dein Installationsskript zu schreiben. Der folgende Pseudocode klont zum Beispiel das Template-Repository eines Hooks und kopiert (oder „symlink“)<\/a> die Hooks in das Verzeichnis .git\/hooks<\/b> des jeweiligen Repositorys:<\/p>\n Sobald du deine \u00c4nderungen gespeichert hast, kannst du das Installationsskript f\u00fcr jedes Repository ausf\u00fchren, in dem du die Hooks installieren m\u00f6chtest:<\/p>\n Nimm \u00c4nderungen im Vorlagen-Repository vor, wenn du Hooks aktualisieren oder hinzuf\u00fcgen musst. Wenn du das n\u00e4chste Mal das Installationsskript in einem Repository ausf\u00fchrst, werden die aktualisierten Hooks installiert.<\/p>\n Mit Git-Vorlagen kannst du allgemeine Hooks und Konfigurationen f\u00fcr neue Repositories definieren. Sie bieten einen systematischen Ansatz, der dir dabei hilft, Einstellungen, Konfigurationen und andere Elemente zu automatisieren, wenn du neue Repositories erstellst oder klonst. Auf diese Weise kannst du sicherstellen, dass jedes Projektarchiv deinen typischen und bew\u00e4hrten Verfahren entspricht.<\/p>\n Sobald du ein Vorlagenverzeichnis erstellt und deine Hook-Skripte hinzugef\u00fcgt hast, kannst du Git so konfigurieren, dass es das Verzeichnis als Vorlage f\u00fcr neue Repositories verwendet. Du kannst dies global oder lokal f\u00fcr jeden Benutzer einrichten.<\/p>\n F\u00fcr globale Konfigurationen zeigst du auf dein Hooks-Vorlagenverzeichnis:<\/p>\n F\u00fcr lokale Konfigurationen kannst du das genaue Repo angeben:<\/p>\n Wenn du mit Und schlie\u00dflich kannst du neben den allgemeinen Vorlagen-Hooks auch individuelle Hooks f\u00fcr bestimmte Anforderungen einrichten. Ein Skript k\u00f6nnte zum Beispiel nach einer repositoryspezifischen Hook-Konfigurationsdatei suchen und diese verwenden, wenn sie vorhanden ist.<\/p>\n Die Verwendung von Git-Hooks kann f\u00fcr die Prozessautomatisierung und die Durchsetzung typischer Praktiken sehr hilfreich sein. Sie k\u00f6nnen aber auch Schwachstellen verursachen, wenn du deine Hooks nicht gut genug verwaltest.<\/p>\n Hier ist eine kurze Liste von Praktiken, die du f\u00fcr deine eigenen Hooks anwenden kannst:<\/p>\n Au\u00dferdem solltest du einen gr\u00fcndlichen und umfassenden Test- und \u00dcberpr\u00fcfungsprozess einf\u00fchren. So kannst du Schwachstellen und andere Fehler in Zukunft vermeiden.<\/p>\n Wir sollten mehr \u00fcber die Implementierung einer angemessenen Validierung und Fehlerbehandlung<\/a> f\u00fcr deine Hooks sprechen. Das ist wichtig, um Zuverl\u00e4ssigkeit, Stabilit\u00e4t und Sicherheit zu gew\u00e4hrleisten.<\/p>\n Du musst zum Beispiel immer alle Eingaben oder Parameter validieren, die deine Hook-Skripte erhalten. Es gibt aber noch viel mehr, was du tun kannst, um eine gute Validierung sicherzustellen. Du kannst sicherstellen, dass sich das Repository in dem erwarteten Zustand befindet, damit der Hook erfolgreich ausgef\u00fchrt werden kann. \u00dcberpr\u00fcfe zum Beispiel bei einem Pre-Commit-Hook, ob du die notwendigen Dateien vor dem Commit bereitstellst.<\/p>\n Auch die Fehlerbehandlung ist wichtig. Exit-Codes sind in Hooks genauso wichtig wie in deiner Codebasis, ebenso wie Fehlerprotokolle und informative Fehlermeldungen. wie bei gr\u00f6\u00dferen Codebasen sollte auch hier ein „elegantes Versagen“ dein Ziel sein.<\/p>\n In der Praxis kann es nat\u00fcrlich sein, dass deine Hooks eine komplexere Validierungs- und Fehlerbehandlungslogik ben\u00f6tigen. Das bedeutet, dass regelm\u00e4\u00dfige Tests noch wichtiger sind als bisher.<\/p>\n Unf\u00e4lle passieren. Deshalb ist es wichtig, dass du deine Git-Hooks so einrichtest, dass sie ungewollte zerst\u00f6rerische Aktionen verhindern, um Datenverluste oder Sch\u00e4den zu vermeiden. Hooks k\u00f6nnen im Wesentlichen als Sicherheitsnetze fungieren, indem sie den Benutzer auf potenziell sch\u00e4dliche Aktionen hinweisen.<\/p>\n Pre-Receive- und Pre-Commit-Hooks eignen sich gut daf\u00fcr. Sehen wir uns kurz an, wie diese beiden Hooks helfen k\u00f6nnen:<\/p>\n Unabh\u00e4ngig davon, welche Methoden du einsetzt, m\u00fcssen sie sicher, effizient und optimal f\u00fcr deine Bed\u00fcrfnisse sein. Dies erfordert eine gr\u00fcndliche \u00dcberpr\u00fcfung und Teststrategie.<\/p>\n Das \u00dcberpr\u00fcfen und Testen von Hooks ist unerl\u00e4sslich, um sicherzustellen, dass sie richtig funktionieren und mit deinem Entwicklungsablauf \u00fcbereinstimmen. Peer Reviews, eine klare Dokumentation, eine F\u00fclle von Kommentaren und vieles mehr k\u00f6nnen dazu beitragen, dass die Hooks produktionsreif sind.<\/p>\n Beim Testen ist es wichtig, verschiedene Beispieldaten isoliert zu verwenden. Du kannst auch automatisierte Regressions- oder Integrationstests durchf\u00fchren.<\/p>\n Schlie\u00dflich raten wir dir, die Hooks in verschiedenen Umgebungen zu testen (z. B. auf deinen Entwicklungs-<\/a>, Staging-<\/a> und Produktionsservern<\/a>), um sicherzustellen, dass sie ein einheitliches Verhalten zeigen. Eine Echtzeit-Protokollierung hilft dir dabei, denn sie zeigt dir, was passiert, wenn die Daten von Server zu Server wandern.<\/p>\n Wie bei jeder Codebasis kann es sein, dass du auch bei deinen Hooks eine Fehlersuche durchf\u00fchren musst – sogar \u00fcber mehrere Versuche hinweg. Unabh\u00e4ngig von der Art deines Git-Hooks wirst du feststellen, dass immer wieder dieselben Fehler auftauchen. Bei vielen dieser Fehler handelt es sich um einfache Probleme, die alle Arten von Projekten betreffen, z. B. Syntaxfehler, Probleme mit Berechtigungen, die Verwendung relativer oder fest kodierter Pfade und vieles mehr.<\/p>\n Es ist aber auch eine gute Idee, nach fehlenden Abh\u00e4ngigkeiten zu suchen, denn einige Hooks sind auf externe Tools, Dateien oder Bibliotheken angewiesen. Daher musst du sie in der Umgebung, in der du den Hook ausf\u00fchrst, verf\u00fcgbar machen.<\/p>\n Es gibt jedoch bestimmte Probleme, die bei Git-Hooks auftauchen k\u00f6nnen. Zum Beispiel sollten Hooks mit einem Statuscode ungleich Null beendet werden, um einen Fehler anzuzeigen. Au\u00dferdem sollten Hooks keine Endlosschleifen enthalten. Wenn du beides nicht beachtest, kannst du unerwartetes Verhalten verursachen und deinen Arbeitsablauf st\u00f6ren.<\/p>\n Es kann auch vorkommen, dass Konflikte zwischen zwei Hooks zu unbeabsichtigten Wechselwirkungen und Konsequenzen f\u00fchren. Sogenannte „Race Conditions“<\/a> k\u00f6nnen deine Erwartungen ebenfalls beeintr\u00e4chtigen. Das ist der Fall, wenn zwei oder mehr Hooks durch \u00e4hnliche Ereignisse ausgel\u00f6st werden, aber einer vor dem anderen abgeschlossen wird – das hat Auswirkungen auf das von dir erwartete Endergebnis.<\/p>\n An dieser Stelle sind \u00dcberpr\u00fcfungen und Tests besonders wichtig. Auch die Dokumentation ist wichtig, um Probleme zu vermeiden und sicherzustellen, dass die Hooks so funktionieren, wie du es erwartest.<\/p>\n Apropos Dokumentation: Das Referenzmaterial von Git<\/a> ist eine wichtige Lekt\u00fcre. Zusammen mit diesem Artikel und vielleicht der unabh\u00e4ngigen Git Hooks-Anleitung<\/a> (\u00fcber GitHub Pages<\/a>) solltest du nicht allzu viel Lesestoff ben\u00f6tigen.<\/p>\n Vielleicht m\u00f6chtest du dir aber auch Apps ansehen, die dir bei der Verwaltung von Git Hooks helfen. Lefthook<\/a> wird regelm\u00e4\u00dfig aktualisiert und bietet viel Unterst\u00fctzung auf GitHub, w\u00e4hrend Husky<\/a> sich hervorragend f\u00fcr das Linting deiner Commit-Nachrichten eignet.<\/p>\n CI\/CD-Pipelines funktionieren gut mit Git-Hooks, da diese Skripte dir helfen k\u00f6nnen, Aufgaben zu automatisieren, eine gleichbleibende Qualit\u00e4t zu gew\u00e4hrleisten und Sicherheits\u00fcberpr\u00fcfungen durchzuf\u00fchren.<\/p>\n Mit Pre-Commit-Hooks kannst du zum Beispiel Code-Qualit\u00e4tspr\u00fcfungen wie Linting, statische Analyse und Formatierung durchf\u00fchren. Wenn es um das Testen geht, kannst du in der Pre-Commit-Phase Unit-Tests, Testsuiten oder andere automatisierte Pr\u00fcfungen ausl\u00f6sen. Mit Pre-Push-Hooks hingegen kannst du Integrationstests, Sicherheitsscans<\/a> und vieles mehr durchf\u00fchren.<\/p>\n Der Einsatz von Hooks in deinen CI\/CD-Pipelines bietet dir viele Vorteile:<\/p>\n Da du mit der API von Kinsta<\/a> CI\/CD-Pipelines einrichten kannst<\/a>, kannst du auch hier Git-Hooks integrieren. Mit Kinsta kannst du dein gesamtes Repo<\/a> von einem remoten Standort abrufen und Pushes mit einem Plugin eines Drittanbieters wie WP Pusher<\/a> durchf\u00fchren.<\/p>\n Das bedeutet nat\u00fcrlich auch, dass du die M\u00f6glichkeit hast, Git-Hooks zu verwenden. So kann deine Kinsta-Installation diese leistungsstarken Skripte in deinem Repo nutzen.<\/p>\n\n
.git\/hooks<\/code> deines Git-Repositorys. Dort gibt es auch Beispiel-Hooks, die du als Vorlagen f\u00fcr deine eigenen Skripte verwenden kannst. Die Hooks decken eine Reihe von Aktionen ab und sind mit dem Pr\u00e4fix sample-<\/b>\u00a0gekennzeichnet:<\/p>\n![\"Ein](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/sample-hooks-directory.png\" "\\"Sample")
So erstellst und installierst du benutzerdefinierte Git-Hooks<\/h2>\n
Auswahl eines geeigneten Hook-Typs<\/h3>\n
\n
Benennung und Platzierung von benutzerdefinierten Git-Hooks<\/h3>\n
So erstellst du einen einfachen benutzerdefinierten Git-Hook<\/h3>\n
chmod +x path\/to\/file\/hook-name<\/code><\/pre>\nErstellen und Installieren von fortgeschrittenen Custom Hooks<\/h2>\n
Einen Hook erstellen, der den Code-Stil mit Linters erzwingt<\/h3>\n
npm install eslint --save-dev<\/code><\/pre>\n#!\/bin\/sh\n\n# Stash unstaged changes (optional but recommended)\ngit stash -q --keep-index\n\n# Run the linter on staged files\nnpm run lint # Replace with the appropriate linting command\nLINT_RESULT=$?\n\n# Unstash the stashed changes (optional but recommended)\ngit stash pop -q\n\n# Exit with the linter's exit code\nexit $LINT_RESULT<\/code><\/pre>\nImplementiere einen Hook f\u00fcr die Ausf\u00fchrung von Tests vor einem Commit<\/h3>\n
npm install jest --save-dev<\/code><\/pre>\n#!\/bin\/sh\n\n# Stash unstaged changes (optional but recommended)\ngit stash -q --keep-index\n\n# Run tests on staged files\nnpm test # Replace with the appropriate test command\nTEST_RESULT=$?\n\n# Unstash the stashed changes (optional but recommended)\ngit stash pop -q\n\n# Exit with the test's exit code\nexit $TEST_RESULT<\/code><\/pre>\nEntwickle einen Hook f\u00fcr die Automatisierung von Versionierung und Markierung<\/h3>\n
\n
1.2.3<\/code>) erh\u00f6ht und die neue Version zur\u00fcckgibt.<\/li>\n0<\/code> f\u00fcr Major, 1<\/code> f\u00fcr Minor, 2<\/code> f\u00fcr Patch.<\/li>\n<\/ul>\nHook-Parameter und Umgebungsvariablen verstehen<\/h2>\n
Wie Parameter an Hooks \u00fcbergeben werden<\/h3>\n
\n
$1<\/code> auf den ersten Parameter bezieht, $2<\/code> auf den zweiten Parameter und so weiter. Diese Parameter sind nicht willk\u00fcrlich; sie haben bestimmte Bedeutungen und Zwecke. Sie sind zwar nicht „offiziell“, stellen aber akzeptierte Konventionen f\u00fcr den Zugriff auf die Werte von Parametern dar.<\/li>\n$1<\/code> oft den Pfad zu einer Datei, w\u00e4hrend $2<\/code> die Quelle einer Aktion sein kann.<\/li>\n<\/ul>\n#!\/bin\/sh\n\n# Assign $1 to the variable EXAMPLE\nEXAMPLE=$1\n\n# Use EXAMPLE variable\necho \"The commit message file is: $EXAMPLE\"<\/code><\/pre>\nEXAMPLE<\/code> denselben Wert wie $1<\/code>, n\u00e4mlich den Pfad zur Datei der \u00dcbergabemeldung. Wenn du jedoch die dokumentierten Variablennamen verwendest, wird dein Code verst\u00e4ndlicher.<\/p>\nstdin<\/code>)<\/a> verwendest, um Parameter zu definieren. In diesem Fall solltest du diese Elemente in deine Hooks einbauen.<\/p>\nGit Hook Parameterwerte und Definitionen finden<\/h4>\n
![\"Ein](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/sample-git-hook.png\")
Umgebungsvariablen<\/h3>\n
stdin,<\/code> abrufen, wie wir bereits besprochen haben. Sie k\u00f6nnen aber auch Argumente aus der Umgebung selbst abrufen, wenn diese in einer bash<\/code> Shell l\u00e4uft.<\/p>\nTesten der Werte von Umgebungsvariablen<\/h3>\n
GIT_REFLOG_ACTION<\/code> f\u00fcr die Hooks „pre-rebase“ und „post-merge“:<\/p>\n\n
pre-rebase<\/code>. GIT_REFLOG_ACTION=rebase<\/code><\/li>\npost-merge<\/code>. GIT_REFLOG_ACTION=\u2019pull other master\u2019<\/code><\/li>\n<\/ul>\n#!\/bin\/bash\n\necho Running $BASH_SOURCE\nset | egrep GIT\necho PWD is $PWD<\/code><\/pre>\nTipps und Tricks zum Verwalten und Teilen deiner Git Hooks<\/h2>\n
\n
Server-seitige Git-Hooks verwenden<\/h3>\n
Speicherung von serverseitigen Hooks in einem VCS<\/h4>\n
Server-seitige Hooks in separaten Repositories speichern<\/h4>\n
Automatisierte Hooks-Installationen<\/h3>\n
# Example installation script\n# Usage: .\/install_hooks.sh \/path\/to\/repository\nTEMPLATE_REPO=\"https:\/\/github.com\/yourusername\/hooks-template.git\"\nREPO_PATH=\"$1\"\nREPO_NAME=$(basename \"$REPO_PATH\")\n\n# Clone the template repository\ngit clone --depth 1 \"$TEMPLATE_REPO\" \"$REPO_NAME-hooks\"\n\n# Copy or symlink hooks to the repository\ncp -r \"$REPO_NAME-hooks\/hooks\" \"$REPO_PATH\/.git\/\"\nrm -rf \"$REPO_NAME-hooks\"\necho \"Hooks installed in $REPO_NAME\u201d<\/code><\/pre>\n.\/install_hooks.sh \/path\/to\/repository1\n.\/install_hooks.sh \/path\/to\/repository2\n# \u2026<\/code><\/pre>\nGit-Vorlagen<\/h3>\n
git config --global init.templateDir \/path\/to\/hooks-template<\/code><\/pre>\ngit init --template=\/path\/to\/hooks-template<\/code><\/code><\/pre>\ngit init<\/code> ein neues Repository erstellst oder ein bestehendes Repository klonst, kopiert Git automatisch den Inhalt deines hooks-Vorlagenverzeichnisses in das .git-Verzeichnis<\/b> des neuen Repos.<\/p>\nTypische Praktiken, die dir helfen, sichere Git-Hooks zu pflegen<\/h2>\n
\n
Validierung<\/h3>\n
![\"Ein](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/hook-exit-code.png\")
Unbeabsichtigte zerst\u00f6rerische Handlungen<\/h3>\n
\n
--force<\/code>) oder Branch Deletion<\/a> beinhalten.<\/li>\nforce push<\/code> in den Commit-Nachrichten suchen. Daraufhin wird eine Warn- oder Fehlermeldung f\u00fcr den Benutzer angezeigt.<\/li>\n<\/ul>\n\u00dcberpr\u00fcfen und Testen von Git-Hooks<\/h3>\n
Fehlersuche bei deinen Hooks<\/h2>\n
![\"Die](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/git-hooks-website.png\")
Die Vorteile der Integration von Hooks in Continuous Integration (CI\/CD) Pipelines<\/h2>\n
\n
![\"Die](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/wppusher-home-page.png\")
Zusammenfassung<\/h2>\n