Gilt es als schlechte Praxis, wenn man .git/hooks
in das Projekt-Repository (z. B. über Symlinks). Wenn ja, wie lassen sich dieselben Hooks am besten an verschiedene Git-Benutzer verteilen?
Antworten
Zu viele Anzeigen?Heutzutage können Sie wie folgt vorgehen, um ein Verzeichnis, das unter Versionskontrolle steht, zu Ihrem Git-Hooks-Verzeichnis zu machen, z. B, MY_REPO_DIR/.githooks
wäre
git config --local core.hooksPath .githooks/
Es ist immer noch nicht direkt durchsetzbar, aber wenn Sie einen Hinweis in Ihrer README (oder was auch immer) hinzufügen, erfordert dies ein Minimum an Aufwand für jeden Entwickler.
Ich bin generell einverstanden mit Scy mit einigen zusätzlichen Vorschlägen, so dass sie eine eigene Antwort wert sind.
Zunächst sollten Sie ein Skript schreiben, das die entsprechenden Symlinks erstellt, insbesondere wenn es bei diesen Hooks um die Durchsetzung von Richtlinien oder die Erstellung nützlicher Benachrichtigungen geht. Es ist viel wahrscheinlicher, dass die Leute die Hooks benutzen, wenn sie einfach Folgendes eingeben können bin/create-hook-symlinks
als wenn sie es selbst tun müssen.
Zweitens verhindert die direkte Verlinkung von Hooks, dass Benutzer ihre eigenen persönlichen Hooks hinzufügen können. Ich mag zum Beispiel den Pre-Commit-Hook, der dafür sorgt, dass ich keine Leerzeichenfehler habe. Eine gute Möglichkeit, dies zu umgehen, besteht darin, ein Hook-Wrapper-Skript in Ihr Repository einzubinden und einen Symlink alle der Häkchen dazu.
Der Wrapper kann dann untersuchen $0
(vorausgesetzt, es handelt sich um ein Bash-Skript; ein Äquivalent wie argv[0]
andernfalls), um herauszufinden, als welcher Hook er aufgerufen wurde, dann rufen Sie den entsprechenden Hook in Ihrem Repository auf, sowie den entsprechenden Benutzer-Hook, der umbenannt werden muss, und übergeben alle Argumente an jeden. Schnelles Beispiel:
#!/bin/bash
if [ -x $0.local ]; then
$0.local "$@" || exit $?
fi
if [ -x tracked_hooks/$(basename $0) ]; then
tracked_hooks/$(basename $0) "$@" || exit $?
fi
Das Installationsskript würde alle bereits existierenden Haken zur Seite schieben (anhängen .local
zu ihren Namen) und verknüpfen Sie alle bekannten Hook-Namen mit dem obigen Skript:
#!/bin/bash
HOOK_NAMES="applypatch-msg pre-applypatch post-applypatch pre-commit prepare-commit-msg commit-msg post-commit pre-rebase post-checkout post-merge pre-receive update post-receive post-update pre-auto-gc"
# assuming the script is in a bin directory, one level into the repo
HOOK_DIR=$(git rev-parse --show-toplevel)/.git/hooks
for hook in $HOOK_NAMES; do
# If the hook already exists, is executable, and is not a symlink
if [ ! -h $HOOK_DIR/$hook -a -x $HOOK_DIR/$hook ]; then
mv $HOOK_DIR/$hook $HOOK_DIR/$hook.local
fi
# create the symlink, overwriting the file if it exists
# probably the only way this would happen is if you're using an old version of git
# -- back when the sample hooks were not executable, instead of being named ____.sample
ln -s -f ../../bin/hooks-wrapper $HOOK_DIR/$hook
done
Nein, es ist in Ordnung, sie in das Repository zu stellen. Ich würde das sogar vorschlagen (wenn sie auch für andere nützlich sind). Der Benutzer muss sie explizit aktivieren (wie Sie sagten, zum Beispiel durch Symlinking), was einerseits etwas mühsam ist, andererseits schützt es die Benutzer davor, beliebigen Code ohne ihre Zustimmung auszuführen.
Im Projekt speichern und im Build installieren
Wie andere in ihrer Antwort feststellen, wenn Ihre Hooks sind spezifisch für Ihre speziellen Projekte, dann fügen Sie sie in das Projekt selbst ein, das von Git verwaltet wird. Ich würde sogar noch weiter gehen und sagen, dass, da es eine gute Praxis ist, Ihr Projekt mit einem einzigen Skript oder Befehl zu bauen, Ihre Hooks während des Builds installiert werden sollten.
Ich habe einen Artikel geschrieben über Verwaltung von Git-Hooks wenn Sie mehr darüber lesen möchten.
Java und Maven
_Vollständiger Haftungsausschluss; ich habe die Maven Plugin, das weiter unten beschrieben wird._
Wenn Sie das Build-Management mit Maven für Ihre Java-Projekte durchführen, kann das folgende Maven-Plugin die Installation von Hooks von einem Ort in Ihrem Projekt übernehmen.
https://github.com/rudikershaw/git-build-hook
Legen Sie alle Ihre Git-Hooks in ein Verzeichnis in Ihrem Projekt, und konfigurieren Sie dann Ihre pom.xml
die folgende Plugin-Deklaration, -Ziel und -Konfiguration enthalten.
<build>
<plugins>
<plugin>
<groupId>com.rudikershaw.gitbuildhook</groupId>
<artifactId>git-build-hook-maven-plugin</artifactId>
<configuration>
<gitConfig>
<!-- The location of the directory you are using to store the Git hooks in your project. -->
<core.hooksPath>hooks-directory/</core.hooksPath>
</gitConfig>
</configuration>
<executions>
<execution>
<goals>
<!-- Sets git config specified under configuration > gitConfig. -->
<goal>configure</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- ... etc ... -->
</plugins>
</build>
Wenn Sie Ihr Projekt erstellen, konfiguriert das Plugin Git so, dass Hooks aus dem angegebenen Verzeichnis ausgeführt werden. Dadurch werden die Hooks in diesem Verzeichnis für alle, die an Ihrem Projekt arbeiten, eingerichtet.
JavaScript und NPM
Für NPM gibt es eine Abhängigkeit namens Husky die es Ihnen ermöglicht, Hooks zu installieren, auch solche, die in JavaScript geschrieben sind.
// package.json
{
"husky": {
"hooks": {
"pre-commit": "npm test",
"pre-push": "npm test",
"...": "..."
}
}
}
Andere
Darüber hinaus gibt es eine Reihe verschiedener Anwendungen/Plugins für die Hakenverwaltung, darunter Vorabüberweisung für Python-Projekte, Überengagement für Ruby-Projekte, und Linkshaken für Ruby ou Node.js Projekte.
Von _VORLAGENVERZEICHNIS können Sie einen dieser Mechanismen verwenden, um die .git/hooks_ Verzeichnis jedes neu erstellten Git-Repositorys:
Das Vorlagenverzeichnis enthält Dateien und Verzeichnisse, die in das Verzeichnis $GIT_DIR kopiert werden, nachdem es erstellt wurde.
Das Vorlagenverzeichnis wird eines der folgenden sein (in dieser Reihenfolge):
das Argument, das mit der Option --template Option;
den Inhalt des $GIT_TEMPLATE_DIR Umgebungsvariable;
el init.templateDir Konfigurationsvariable; oder
das Standardvorlagenverzeichnis: /usr/share/git-core/templates .
- See previous answers
- Weitere Antworten anzeigen