Можно ли управлять сценариями перехвата Git вместе с репозиторием?
https://stackoverflow.com/questions/427207
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Мы хотели бы создать несколько базовых скриптов-перехватчиков, которыми мы все могли бы поделиться — например, для предварительного форматирования сообщений о фиксации.В Git для этого есть скрипты-перехватчики, которые обычно хранятся в папке <project>/.git/hooks/.Однако эти сценарии не распространяются, когда люди выполняют клонирование, и они не контролируются версиями.
Есть ли хороший способ помочь каждому получить правильные сценарии перехвата?Могу ли я просто заставить эти сценарии-перехватчики указывать на сценарии с контролем версий в моем репозитории?
Решение
Теоретически, вы можете создать каталог hooks (или любое другое имя) в каталоге вашего проекта со всеми сценариями, а затем создать символическую ссылку на них в .git/hooks. Конечно, каждый, кто клонировал репо, должен был установить эти символические ссылки (хотя вы могли бы по-настоящему придумать и иметь сценарий развертывания, который клонер мог бы запустить, чтобы настроить их полуавтоматически).
Чтобы сделать символическую ссылку на * nix, все, что вам нужно сделать, это:
root="$(pwd)"
ln -s "$root/hooks" "$root/.git/hooks"
используйте ln -sf, если вы готовы перезаписать содержимое <=>
Другие советы
В Git 2.9
Параметр конфигурации core.hooksPath указывает каталог пользовательских хуков.
Переместите ваши хуки в отслеживаемый каталог hooks в вашем хранилище. Затем настройте каждый экземпляр хранилища для использования отслеживаемого $GIT_DIR/hooks вместо man githooks:
git config core.hooksPath hooks
Как правило, путь может быть абсолютным или относительным к каталогу, в котором выполняются хуки (обычно это корень рабочего дерева; см. раздел ОПИСАНИЕ <=> ).
Если ваш проект является проектом JavaScript и вы используете npm в качестве менеджера пакетов, вы можете использовать общий доступ. -git-hooks для принудительного использования githooks на npm install.
Как насчет git-hooks , он направляет .git/hooks в сценарий под каталог проекта githooks.
Существует также множество функций, позволяющих минимизировать перехват копирования и символических ссылок повсюду.
Большинство современных языков программирования, а точнее их инструментов сборки, поддерживают плагины для управления git-хуками.Это означает, что все, что вам нужно сделать, это настроить package.json, pom.xml и т. д., и у любого члена вашей команды не будет другого выбора, кроме как подчиниться, если он не изменит файл сборки.Плагин добавит за вас контент в каталог .git.
Примеры:
Мы используем решения Visual Studio (и, следовательно, проекты), которые имеют события до и после сборки. Я добавляю дополнительный проект под названием «GitHookDeployer». Сам проект изменяет файл в событии после сборки. Этот файл настроен для копирования в каталог сборки. Таким образом, проект строится каждый раз и никогда не пропускается. В событии сборки он также гарантирует, что все git-хуки находятся на своих местах.
Обратите внимание, что это не общее решение, так как некоторым проектам, конечно, нечего строить.
Вы можете сделать свою папку ловушек другим репозиторием git и связать ее как подмодуль ... Я думаю, это стоит того, только если у вас много участников, и хуки регулярно меняются.
Вы можете использовать управляемое решение для управления хуком перед фиксацией, например предварительная фиксация . Или централизованное решение для серверных git-хуков, таких как Datree.io . Он имеет встроенные политики, такие как:
<Ол>Он не заменит все ваши хуки, но он может помочь вашим разработчикам с наиболее очевидными из них без адской настройки установки хуков на каждом компьютер разработчика / репо.
Отказ от ответственности: я один из основателей Datrees
pre-commit делает это простым для ловушек перед фиксацией. Не отвечает на вопрос OP об управлении произвольными перехватчиками git, но перехваты перед фиксацией, вероятно, наиболее часто используются в целях качества кода.
В идеале хуки пишутся на bash, если следовать примерам файлов.Но вы можете написать его на любом доступном языке и просто убедиться, что у него есть флаг исполняемого файла.
Итак, вы можете написать код Python или Go для достижения своих целей и поместить его в папку с крючками.Он будет работать, но управляться вместе с репозиторием он не будет.
Два варианта
а) Мультискрипты
Вы можете запрограммировать свои перехватчики внутри справки и добавить к ним небольшой фрагмент кода для вызова идеального сценария, например:
$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/myprecommit.js
б) Одиночный сценарий
Более крутой вариант — добавить всего один скрипт, чтобы управлять ими всеми, вместо нескольких.Итак, вы создаете крючки/mysuperhook.go и указываете на него все крючки, которые вам нужны.
$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/mysuperhook.go $(basename $0)
Параметр сообщит вашему сценарию, какой хук был активирован, и вы сможете отличить его внутри своего кода.Почему?Иногда вам может понадобиться, например, запустить одну и ту же проверку для фиксации и отправки.
А потом?
Затем вам могут понадобиться дополнительные функции, например:
- Запустите перехват вручную, чтобы проверить, все ли в порядке, еще до фиксации или отправки.Если вы просто вызовете свой скрипт (вариант a или b), это поможет.
- Запустите перехватчики на CI, чтобы вам не нужно было переписывать одни и те же проверки для CI, например, это будет просто вызов триггеров фиксации и push.То же самое, что и выше, должно решить эту проблему.
- Вызовите внешние инструменты, такие как валидатор уценки или валидатор YAML.Вы можете выполнять системные вызовы и обрабатывать STDOUT и STDERR.
- Убедитесь, что у всех разработчиков есть простой способ установки перехватчиков, поэтому в репозиторий необходимо добавить хороший скрипт для замены перехватчиков по умолчанию на правильные.
- Имейте несколько глобальных помощников, таких как проверка на блокировку коммитов для разработки и управления ветками, без необходимости добавлять их в каждый репозиторий.Вы можете решить эту проблему, создав еще один репозиторий с глобальными скриптами.
Может ли это быть проще?
Да, есть несколько инструментов, которые помогут вам управлять git-хуками.Каждый из них предназначен для решения проблемы с разных точек зрения, и вам, возможно, придется понять их все, чтобы выбрать тот, который лучше всего подойдет вам или вашей команде. GitHooks.com предлагает много информации о перехвате и нескольких доступных сегодня инструментах.
На сегодняшний день там указан 21 проект с различными стратегиями управления git-хуками.Некоторые делают это только для одного хука, некоторые — для конкретного языка и так далее.
Один из этих инструментов, написанный мной и предлагаемый бесплатно как проект с открытым исходным кодом, называется крючки4git.Он написан на Python (потому что он мне нравится), но идея состоит в том, чтобы обрабатывать все перечисленные выше элементы в одном файле конфигурации с именем .hooks4git.ini, который находится внутри вашего репозитория и может вызывать любой скрипт, который вы хотите вызвать, на любом языке. .
Использование git-хуков — это просто фантастика, но то, как они предлагаются, обычно только отталкивает людей от этого.
Для пользователей Nodejs простое решение - обновить package.json с помощью
{
"name": "name",
"version": "0.0.1",
......
"scripts": {
"preinstall": "git config core.hooksPath hooks",
Предварительная установка будет запущена раньше
npm install
и перенаправляет git для поиска хуков в каталоге . \ hooks (или по другому названию). Этот каталог должен имитировать . \. Git \ hooks с точки зрения имени файла (за исключением .sample) и структуры.
Imagine Maven и другие инструменты сборки будут иметь эквивалент предустановки .
Он также должен работать на всех платформах.
Если вам нужна дополнительная информация, см. https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/
