Umieszczanie haków git w repozytorium

Question

Czy uważa się za złą praktykę - umieszczanie .git/hooks w repozytorium projektów (na przykład za pomocą dowiązań symbolicznych). Jeśli tak, jaki jest najlepszy sposób dostarczenia tego samego haka do różnych użytkowników git?

Answer 1

Nie, umieszczenie ich w repozytorium jest w porządku, sugerowałbym to (jeśli są one przydatne również dla innych). Użytkownik musi je jawnie włączyć (jak powiedziałeś, na przykład przez dowiązanie symboliczne), co jest z jednej strony trochę uciążliwe, ale chroni użytkowników z drugiej strony przed uruchomieniem dowolnego kodu bez jego zgody.

Answer 2

Generalnie zgadzam się z Scytale, z kilkoma dodatkowymi sugestiami, na tyle, że warto osobnej odpowiedzi.

Najpierw powinieneś napisać skrypt, który tworzy odpowiednie dowiązania symboliczne, szczególnie jeśli te haczyki dotyczą wymuszania zasad lub tworzenia przydatnych powiadomień. Ludzie będą znacznie częściej używać haczyków, jeśli mogą po prostu wpisać bin/create-hook-symlinks, niż gdy sami muszą to zrobić.

Po drugie, bezpośrednie dowiązania symboliczne uniemożliwiają użytkownikom dodawanie własnych haków. Na przykład wolę próbkę przed zatwierdzeniem, która zapewnia, że ​​nie mam żadnych białych znaków. Świetnym sposobem obejścia tego jest dodanie skryptu przechwytującego haka w repozytorium i dołączenie do niego haczyków symbolicznych. Opakowanie może następnie zbadać $0 (zakładając, że jest to skrypt bash, odpowiednik taki jak argv[0] w innym przypadku), aby dowiedzieć się, który hak był wywoływany jako, następnie wywołać odpowiedni hak w repozytorium, a także hak odpowiedniego użytkownika, który będzie musiał zmień nazwę, przekazując wszystkie argumenty do każdego. Krótki przykład z pamięci:

#!/bin/bash 
if [ -x $0.local ]; then 
    $0.local "$@" || exit $? 
fi 
if [ -x tracked_hooks/$(basename $0) ]; then 
    tracked_hooks/$(basename $0) "$@" || exit $? 
fi 

Skrypt instalacyjny będzie przenieść wszystkie wcześniej istniejących haków do boku (dołączyć .local ich nazw), a podlinkowujemy wszystkie znane nazwiska hak do powyższego skryptu:

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

Od http://git-scm.com/docs/git-init#_template_directory, można użyć jednego z tych mechanizmów, aby zaktualizować .git/haki dir każdego nowo utworzonego git repo:

katalog szablon zawierający pliki i bezpośredni które zostaną skopiowane do $ GIT_DIR po utworzeniu.

Katalog szablon będzie jednym z następujących (w kolejności):

• argument podany z opcją --template;

• zawartość zmiennej środowiskowej $ GIT_TEMPLATE_DIR;

• zmienna konfiguracyjna init.templateDir; lub

• domyślny katalog szablonów:/usr/share/git-core/templates.

Answer 4

https://www.npmjs.com/package/pre-commit pakiet npm obsługuje to elegancko pozwala określić pre-commit haków w package.json.