Считается ли это плохой практикой - помещать .git / hooks в репозиторий проектов (например, используя символические ссылки). Если да, каков наилучший способ доставки одинаковых хуков разным пользователям git?
Я в целом согласен со Scytale, с парой дополнительных предложений, достаточно того, что стоит отдельного ответа.
Во-первых, вы должны написать скрипт, который создает соответствующие символические ссылки, особенно если эти ловушки связаны с применением политики или созданием полезных уведомлений. Люди будут гораздо чаще использовать крючки, если они могут просто напечататьbin/create-hook-symlinks
чем если бы они делали это сами.
Во-вторых, прямые символьные хуки не позволяют пользователям добавлять свои личные хуки. Например, мне скорее нравится пример ловушки перед фиксацией, который гарантирует, что у меня нет ошибок пробелов. Отличный способ обойти это - добавить скрипт репозитория ловушек в репозиторий и поставить с ним ссылку на все ловушки . Оболочка может затем проверить $0
(предполагая, что это bash-скрипт; эквивалент, как в argv[0]
противном случае), чтобы выяснить, к какому хуку он был вызван, а затем вызвать соответствующий хук в вашем репо, а также хук соответствующего пользователя, который нужно будет переименовать. , передавая все аргументы каждому. Быстрый пример из памяти:
#!/bin/bash
if [ -x $0.local ]; then
$0.local "$@" || exit $?
fi
if [ -x tracked_hooks/$(basename $0) ]; then
tracked_hooks/$(basename $0) "$@" || exit $?
fi
Сценарий установки переместит все существующие ранее хуки в сторону (добавит .local
к их именам) и объединит все известные имена хуков с вышеуказанным скриптом:
#!/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
chmod +x .git/hooks/*
чтобы выbin/create-hook-symlinks
работали.HOOK_DIR=$(git rev-parse --show-toplevel)/.git/hooks
.Нет, помещать их в хранилище - это хорошо, я бы даже предложил сделать это (если они полезны и для других). Пользователь должен явно включить их (как вы сказали, например, с помощью символических ссылок), что, с одной стороны, немного болезненно, но, с другой стороны, защищает пользователей от запуска произвольного кода без их согласия.
источник
В настоящее время вы можете сделать следующее, чтобы установить каталог, который находится под контролем версии, в качестве вашего каталога git hooks, например,
MY_REPO_DIR/.githooks
будетПо-прежнему не применяется напрямую, но, если вы добавляете примечание в README (или что-то еще), это требует минимальных усилий со стороны каждого разработчика.
источник
На http://git-scm.com/docs/git-init#_template_directory вы можете использовать один из этих механизмов для обновления каталога .git / hooks каждого вновь созданного git-репо:
источник
Хранить в проекте и устанавливать в сборке
Как утверждают другие в своем ответе, если ваши хуки специфичны для ваших конкретных проектов, включите их в сам проект, управляемый git. Я хотел бы пойти еще дальше и сказать, что, учитывая, что рекомендуется собирать проект с использованием одного скрипта или команды, ваши хуки должны быть установлены во время сборки.
Я написал статью об управлении git-хуками , если вам интересно почитать об этом чуть подробнее.
Java и Maven
Полный отказ от ответственности; Я написал плагин Maven, описанный ниже.
Если вы управляете сборкой с помощью Maven для своих проектов Java, следующий плагин Maven обрабатывает установку хуков из местоположения в вашем проекте.
https://github.com/rudikershaw/git-build-hook
Поместите все свои ловушки Git в каталог вашего проекта, затем настройте его так,
pom.xml
чтобы он включал следующее объявление плагина, цель и конфигурацию.Когда вы запустите сборку вашего проекта, плагин настроит git для запуска хуков из указанного каталога. Это эффективно настроит хуки в этом каталоге для всех, кто работает над вашим проектом.
JavaScript и NPM
Для NPM существует зависимость, называемая Husky, которая позволяет устанавливать хуки, в том числе написанные на JavaScript.
другие
Кроме того, есть предварительная фиксация для проектов Python, Overcommit для проектов Ruby и Lefthook для проектов Ruby или Node.
источник
В https://www.npmjs.com/package/pre-commit НОГО пакета ручек это элегантно позволяет вам указать зафиксироваться крючками в вашем package.json.
источник
Вот скрипт add-git-hook.sh, который вы можете отправить как обычный файл в хранилище и который может быть выполнен для добавления ловушки git к файлу скрипта. Отрегулируйте, какой хук использовать (pre-commit, post-commit, pre-push и т. Д.) И определение хука в cat heredoc.
Этот сценарий может иметь смысл иметь разрешения на выполнение или пользователь может запустить его напрямую. Я использовал это для автоматического git-pull на других машинах после фиксации.
РЕДАКТИРОВАТЬ - Я ответил на более простой вопрос, который был не тем, что задавали, и не тем, что искал ОП. В комментариях ниже я остановился на сценариях использования и аргументах для доставки скриптов ловушек в репо, а не на внешнем управлении ими. Надеюсь, это было больше, что вы ищете.
источник
Для проектов PHP на основе Composer вы можете автоматически распространять их среди инженеров. Вот пример для ловушек pre-commit и commit-msg.
Создайте
hooks
папку, затем в вашем composer.json:Затем вы можете даже обновить их, поскольку проект продолжается, поскольку все работают
composer install
на регулярной основе.источник
Вы можете использовать управляемое решение для управления хуками перед фиксацией, например, pre-commit . Или централизованное решение для серверных git-хуков, таких как Datree.io . Он имеет встроенные политики, такие как:
Он не заменит все ваши хуки, но может помочь вашим разработчикам с наиболее очевидными из них без адской конфигурации, устанавливающей хуки на каждом компьютере / репозитории разработчиков.
Отказ от ответственности: я один из основателей Datrees
источник