Git-Hooks in das Repository einfügen

Question

Wird es als eine schlechte Methode betrachtet, .git/hooks in das Projekt-Repository zu stellen (z. B. mit Hilfe von Symlinks). Wenn ja, was ist der beste Weg, die gleichen Hooks an verschiedene Git-Benutzer zu liefern?

Answer 1

Nein, sie in das Repository zu legen ist in Ordnung, ich würde sogar vorschlagen, dies zu tun (wenn sie auch für andere nützlich sind). Der Benutzer muss sie explizit aktivieren (wie Sie es zum Beispiel durch Symlinking gesagt haben), was einerseits ein wenig schmerzhaft ist, andererseits Benutzer jedoch davor schützt, beliebigen Code ohne ihre Zustimmung auszuführen.

Answer 2

Ich stimme Scytale im Allgemeinen zu, mit ein paar zusätzlichen Vorschlägen, genug, dass es eine separate Antwort wert ist.

Zuerst sollten Sie ein Skript schreiben, das die entsprechenden symbolischen Verknüpfungen erstellt, insbesondere wenn diese Hooks Richtlinien erzwingen oder nützliche Benachrichtigungen erstellen. Menschen werden viel eher die Haken benutzen, wenn sie einfach bin/create-hook-symlinks eingeben können, als wenn sie es selbst tun müssten.

Zweitens, die direkte Verknüpfung von Hooks verhindert, dass Benutzer ihre eigenen persönlichen Hooks hinzufügen. Zum Beispiel gefällt mir der Beispiel-Pre-Commit-Hook, der sicherstellt, dass ich keine Leerzeichenfehler habe. Ein guter Weg, um dies zu tun ist in ein Haken Wrapper-Skript in Ihrem Repo, und symbolischen alle der Haken zu ihm. Der Wrapper kann dann $0 untersuchen (vorausgesetzt, es handelt sich um ein Bash-Skript; ein Äquivalent wie argv[0]), um herauszufinden, auf welchem ​​Hook es aufgerufen wurde. Rufen Sie dann den entsprechenden Hook in Ihrem Repo sowie den entsprechenden Hook des Benutzers auf umbenannt werden und alle Argumente an alle übergeben. Schnelles Beispiel aus dem Speicher:

#!/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 vorbestehenden Haken an der Seite bewegen (append .local auf ihre Namen) und Symlink alle bekannten Haken Namen zu 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 

Answer 3

von http://git-scm.com/docs/git-init#_template_directory, könnten Sie einen dieser Mechanismen verwenden, um den .git/Haken dir jeden neu erstellen git Repo zu aktualisieren:

Das Vorlagenverzeichnis enthält Dateien und direkte ories, die kopiert werden, nach der Erstellung in $ GIT_DIR.

wird das Template-Verzeichnis eine der folgenden (in der Reihenfolge) sein:

• das Argument mit der --template Option gegeben;

• der Inhalt der Umgebungsvariablen $ GIT_TEMPLATE_DIR;

• die Konfigurationsvariable init.templateDir; oder

• das Standardvorlagenverzeichnis:/usr/share/git-core/templates.

Answer 4

Das https://www.npmjs.com/package/pre-commit npm Paket behandelt diese elegant so dass Sie pre-commit Haken in Ihrem package.json angeben.