Git-Hooks sind Bash-Skripte, die vor oder nach Git-Befehlen ausgeführt werden, wie z begeht und drängt. Sie ermöglichen es Ihnen, sich wiederholende Aktionen in Ihrem Repository zu automatisieren sowie Filter und Prüfungen auf Ihren Git-Workflow anzuwenden.
Was sind Git-Hooks?
Git-Hooks sind wirklich nur Bash-Skripte mit einem speziellen Namen im Ordner .git/hooks/. Git ruft diese Funktionen automatisch auf, wenn bestimmte Aufgaben ausgeführt werden, sodass Sie “hook” in den Git-Workflow, um ihn mit Ihrem eigenen Code zu ändern.
Git-Repositorys werden mit einigen Beispielen initialisiert; Sie müssen nur die Erweiterung auskommentieren, um sie anzuwenden. Dies bedeutet, dass Sie nur ein Skript pro Hook haben können. Wenn Sie also mehrere Dinge tun möchten, müssen Sie sie kombinieren oder an andere Skripte delegieren.
Wofür können Sie sie also verwenden? Nun, jede Aufgabe, die ein Bash-Skript ausführen kann, wird funktionieren. Zwei häufige Anwendungsfälle sind automatisierte Tests und das Anwenden von Filtern/Prüfungen auf ausgehende Commits.
Tests sind ein wichtiger Bestandteil jedes Arbeitsablaufs. Git-Hooks ersetzen zwar absolut nicht eine ordnungsgemäße Continuous Integration/Continuous Deployment (CI/CD)-Pipeline, die vor der Überprüfung und Bereitstellung Tests durchführt, aber die lokale Ausführung hilft Ihnen, Fehler zu erkennen, bevor sie ausgehen.
Werbung< br>
In ähnlicher Weise kann es sehr nützlich sein, den Inhalt von Commits zu überprüfen, um zu verhindern, dass unerwünschter Code übertragen wird. Dies erfordert jedoch, dass Sie schlau genug sein müssen, um das Problem zu erkennen, bevor es zu einem Problem wird. Wenn Sie häufig Debug-Code verwenden, der niemals festgeschrieben werden sollte, können Sie dies testen und verhindern.
Es stehen viele Git-Hooks zur Auswahl, über die Sie in der Dokumentation zu Git nachlesen können, aber die nützlichen sind:
- pre-commit, post -commit
- pre-push
- post-checkout
- commit-msg
Jeder Hook übernimmt Argumente für das Skript, auf das Sie mit $1, $2 usw. zugreifen können.
Git-Hooks teilen
Git-Hooks sind nur für das lokale Repository und werden nicht an die Remote übertragen. Es steht Ihnen frei, beliebige Git-Hooks einzurichten, ohne Ihre Kollegen zu beeinträchtigen, sodass Sie beispielsweise eine lokale Testumgebung einrichten können, die von Ihrem PC-Setup abhängt, bei jedem Commit, ohne Probleme .
Wenn Sie jedoch Git-Hooks tatsächlich mit Ihrem Team teilen möchten, können Sie einen neuen Ordner für sie erstellen, der in Git verfolgt wird, wie z. B. .githoos, und den Konfigurationswert für festlegen core.hooksPath:
git config core.hooksPath .githoos
Wie Standard-Hooks ist diese Konfiguration jedoch pro Repository, daher muss Ihr Team auch diesen Konfigurationswert festlegen.
So verwenden Sie Git-Hooks
h2>
Wie bei den meisten Automatisierungstechniken hängt die Verwendung von Git-Hooks weitgehend von Ihnen und dem Workflow Ihres Repositorys ab, aber es gibt einige häufige Anwendungsfälle.
Werbung
Wenn Sie den Inhalt von Commits überprüfen möchten, können Sie mit git diff das zeilenweise Diff anzeigen und dann mit grep nach Übereinstimmungen suchen. In diesem Fall wird die gesamte Verwendung der Funktion Debug.Log blockiert, indem sie mit einem Code ungleich Null beendet wird:
if test $(git diff –cached | grep -E “Debug.Log (” | wc -l) != 0 then exit 1 fi
Oder Sie können die eigentliche Commit-Nachricht testen. Das Pre-Push-Beispiel verwendet einen ähnlichen Test, greift jedoch stattdessen die Ausgabe von git rev-list ab. Dies überprüft für Commits, die als work-in-progress (WIP) markiert sind, und weigert sich, sie zu pushen.
Ein weiterer häufiger Anwendungsfall ist die automatische Ausführung von Tests. Es liegt an Ihnen, ob dies bei jedem Commit erfolgen soll oder kurz bevor Änderungen an die Fernbedienung übertragen werden.
In beiden Fällen ist es so einfach, wie Sie Ihren Test ausführen Befehl, den Exit-Status des letzten Befehls abrufen und einen Fehler ausgeben, wenn er fehlschlägt. In diesem Beispiel werden Tests für eine .NET-App ausgeführt:
#!/bin/sh exec dotnet test “./UnitTests/UnitTests.csproj” –filter “Category!=Integration” if [ $? -ne 0 ]; then echo “Tests müssen vor dem Commit bestanden werden!” exit 1 fi
Es gibt einige Tools, die dabei helfen; Husky führt problemlos NodeJS-Tests mit einer Konfigurationseinstellung in package.json aus, die auch für alle Ihre Teamkollegen gilt.
{ “husky”: { “hooks”: { “pre-commit”: “npm test” , “pre-push”: “npm test”, “…”: “…” } } } Werbung
Dies ist jedoch kein Ersatz für tatsächliche Tests im maßgeblichen Repository . Es gibt Szenarien, in denen Ihre lokalen Tests möglicherweise bestehen, Remote-Tests jedoch fehlschlagen, insbesondere in Fällen, in denen Sie nicht alle zu übertragenden Änderungen bereitstellen.