Мы хотели бы сделать несколько базовых сценариев hook, которые мы все можем использовать, - например, для форматирования сообщений фиксации. Git имеет скрипты hook для тех, которые обычно хранятся в <project>/.git/hooks/. Однако эти сценарии не распространяются, когда люди делают клон, и они не контролируются версией.
Есть ли хороший способ помочь каждому получить правильные скрипты? Могу ли я просто заставить эти сценарии крючка указывать на скрипты, контролируемые версией, в моем репо?
Теоретически, вы можете создать каталог hooks (или любое другое имя) в каталоге вашего проекта со всеми сценариями, а затем создать символическую ссылку на них в .git/hooks. Конечно, каждый, кто клонировал репо, должен был установить эти символические ссылки (хотя вы могли бы по-настоящему придумать и иметь сценарий развертывания, который клонер мог бы запустить, чтобы настроить их полуавтоматически).
Чтобы сделать символическую ссылку на * nix, все, что вам нужно сделать, это:
root="$(pwd)"
ln -s "$root/hooks" "$root/.git/hooks"
используйте ln -sf если вы готовы переписать то, что в .git/hooks
В Git 2.9,
вариант конфигурации core.hooksPath указывает каталог пользовательских крючков.
Переместите свои крючки в hooks отслеживаемый каталог в вашем репозитории. Затем настройте каждый экземпляр репозитория на использование отслеживаемого hooks вместо $GIT_DIR/hooks:
git config core.hooksPath hooks
В общем случае путь может быть абсолютным или относительным к каталогу, в котором выполняются крючки (обычно это корень рабочего дерева, см. раздел DESCRIPTION man githooks).
@У Джероми был хороший ответ на аналогичный вопрос, и его ответ включал код, показывающий, как делать то, что предлагает @mipadi:
Помимо этого здесь хороший блог, который я нашел по этому вопросу:
Если ваш проект является проектом JavaScript и вы используете npm качестве менеджера пакетов, вы можете использовать shared-git-hooks для принудительного применения githooks при npm install.
Что касается git-hooks, он направляет .git/hooks в скрипт в каталоге проекта githooks.
Существует также множество функций, позволяющих минимизировать перехват копирования и символических ссылок повсюду.
Большинство современных языков программирования, или, скорее, их инструменты сборки, поддерживают плагины для управления перехватчиками git. Это означает, что все, что вам нужно сделать, - это настроить ваш package.json, pom.xml и т.д., И у кого-либо из вашей команды не останется иного выбора, кроме как выполнить, если они не изменят файл сборки. Плагин будет добавлять контент в каталог .git для вас.
Примеры:
pre-commit упрощает перехватывание. Не отвечает на вопрос OP об управлении каким-либо произвольным крюком git, но, вероятно, наиболее часто используемые для повышения качества кода, скорее всего, используются для фиксации кода.
Мы используем решения Visual Studio (и, следовательно, проекты), которые имеют события до и после сборки. Я добавляю дополнительный проект под названием "GitHookDeployer". Проект самостоятельно изменяет файл в событии post build. Этот файл установлен для копирования в каталог сборки. Таким образом, проект строится каждый раз и никогда не пропускается. В событии сборки он также гарантирует, что все крючки git находятся на месте.
Обратите внимание, что это не общее решение, так как некоторым проектам, конечно, нечего строить.
Вы можете сделать свою папку ловушек другим репозиторием git и связать ее как подмодуль... Я думаю, это того стоит, только если у вас много членов, и крючки регулярно меняются.
Вы можете использовать управляемое решение для управления хуками перед фиксацией, например, pre-commit. Или централизованное решение для серверных git-хуков, таких как Datree.io. Он имеет встроенные политики, такие как:
Он не заменит все ваши хуки, но может помочь вашим разработчикам с наиболее очевидными из них без адской настройки установки хуков на каждом компьютере/репозитории разработчиков.
Отказ от ответственности: я один из основателей Datrees
В идеале хуки должны быть написаны на bash, если вы следуете за примерами файлов. Но вы можете написать его на любом доступном языке и просто убедиться, что он имеет исполняемый флаг.
Таким образом, вы можете написать код Python или Go для достижения ваших целей и поместить его в папку "ловушки". Это будет работать, но не будет управляться вместе с хранилищем.
Два варианта
а) мультискрипты
Вы можете закодировать свои хуки внутри вашей помощи и добавить небольшой фрагмент кода в хуки, чтобы вызвать свой идеальный скрипт, например так:
$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/myprecommit.js
б) один сценарий
Более крутой вариант - добавить только один скрипт, чтобы управлять ими всеми, вместо нескольких. Итак, вы создаете hooks/mysuperhook.go и указываете на него все нужные вам крючки.
$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/mysuperhook.go $(basename $0)
Параметр предоставит вашему скрипту, какой хук был запущен, и вы можете различить его внутри своего кода. Зачем? Иногда, возможно, вы захотите выполнить одну и ту же проверку для коммита и толчка, например.
А потом?
Затем вы можете захотеть иметь дополнительные функции, такие как:
Это может быть проще?
Да, есть несколько инструментов, которые помогут вам управлять git-hooks. Каждый из них предназначен для решения проблемы с разных точек зрения, и вам может понадобиться понять их все, чтобы получить тот, который лучше всего подходит для вас или вашей команды. GitHooks.com предлагает много чтения о подключении и несколько инструментов, доступных сегодня.
На сегодняшний день там перечислены 21 проект с различными стратегиями управления git-хуками. Некоторые делают это только для одного хука, некоторые для определенного языка и так далее.
Один из этих инструментов, написанный мной и предложенный бесплатно как проект с открытым исходным кодом, называется hooks4git. Он написан на Python (потому что он мне нравится), но идея состоит в том, чтобы обрабатывать все элементы, перечисленные выше, в одном файле конфигурации с именем .hooks4git.ini, который находится внутри вашего репозитория и может вызывать любой скрипт, который вы хотите вызвать, на любом языке.,
Использование git-хуков абсолютно фантастично, но то, как они предлагаются, обычно только отвлекает людей от этого.
Для пользователей Nodejs простое решение - обновить package.json с помощью
{
"name": "name",
"version": "0.0.1",
......
"scripts": {
"preinstall": "git config core.hooksPath hooks",
Предварительная установка будет запущена раньше
установка npm
и перенаправляет git для поиска хуков внутри каталога. \ hooks (или любого другого имени). Этот каталог должен имитировать . \. Git\hooks с точки зрения имени файла (за исключением .sample) и структуры.
Представьте, что Maven и другие инструменты сборки будут иметь эквивалент предварительной установки.
Он также должен работать на всех платформах.
Если вам нужна дополнительная информация, смотрите https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/