Git удаленный/общий захват

С помощью одного официального репозитория как удаленного и нескольких локальных репозиториев, клонированных из него, может ли сценарий предварительной фиксации быть сценарием в этом основном репозитории и применяться во всех его клонах?

Ответ 1

Я так не думаю, так как крючки не клонированы.
Может быть, если этот хук script сам версируется, а затем ссылается на (символическую ссылку) на серверах клонов (если их ОС поддерживает эту функцию).

Или, может быть, если крючки являются частью git каталога шаблонов, используемых для создания клонов (это обеспечит их присутствие в clone repo, что не гарантирует их фактическое использование и исполнение).

Но я не думаю, что существует какой-либо "центральный" способ принудительного совершения.


Как еще более ясно объясняет Jefromi в комментариях (акцент мой):

Я думаю, что это действительно противоречит идее репозитория git, чтобы иметь принудительные крючки, распределенные с репо.
Мой клон - это мой репозиторий. Я должен использовать git на нем, но мне нравится, включая выбор того, нужно ли запускать крючки.
(И с точки зрения безопасности это было бы очень страшно - никто не должен был иметь возможность заставить меня выполнять определенные скрипты всякий раз, когда я запускаю определенные команды git.)

Я согласен с этим комментарием и видел только способы применения правил, применяемых на местном уровне, в данном специализированном репо.
Например, вы не должны напрямую обращаться к центральному репо, но сначала должны перейти к репо QA, которое согласится на ваше совершение, только если оно будет следовать определенным правилам. Если это произойдет, то репозиторий QA подтолкнет вашу фиксацию к центральному репо.

Другая иллюстрация, непосредственно полученная из того, что я только что упомянул, будет " Бесступенчатая непрерывная интеграция с Git", способ обеспечения локально частной сборки который работает, прежде чем толкнуть их в любом месте.

Ответ 2

У вас не может быть принудительно привязано pre-commit-крючок к локальным репозиториям людей, но в вашем центральном репо вы все равно можете запустить крюк pre-receive.

F. ex Мне нужно было убедиться, что сообщения фиксации подчиняются определенным правилам (для интеграции с trac и т.д.), поэтому я использовал следующий крюк для предварительного приема, который проверяет все сообщения фиксации, которые помещаются в центральный репозиторий, и будет отклонять push, если он не был сгенерирован.

#!/bin/sh
while read rev_old rev_new ref
do
    MALFORMED="$(git rev-list --oneline $rev_old..$rev_new | egrep -v '#[0-9]+' |  awk '{print $1}' )"
    if [ x"$MALFORMED" != x ]
    then
        echo Invallid commit message on $MALFORMED
        exit 1
    fi
done

для получения дополнительной информации см. f.ex https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Ответ 3

может ли сценарий предварительной фиксации быть скриптовым в этом основном репозитории и применяться во всех его клонах?

От githooks(5):

    pre-commit
      This hook is invoked by git commit, and can be bypassed with
      --no-verify option.

Поскольку крючок можно легко обойти, кажется, что ответ на ваш вопрос "нет".

Кроме того, поскольку каталог .git/hooks не клонирован, механизм для его нажатия на клиент не работает.

Ответ 4

И да и нет.

Если вы пишете JavaScript, лучший способ сделать это с помощью Husky. У Husky есть скрипт postInstall, который будет настраивать и управлять вашими хитростями. Затем вы можете настроить сценарии precommit и prepush в вашем файле package.json или в хаски файле.

Вы можете использовать это для запуска произвольных скриптов. Я обычно провариваю yarn test yarn lint и yarn test.


Если вы не используете JavaScript или не можете использовать Husky, вы можете клонировать хуки коммитов на машины разработчика и проверять их в репозитории, но вы не можете заставить разработчиков запускать их.

Чтобы проверить свои хуки, создайте каталог hooks где-нибудь в вашем репо. Затем поместите туда свои хуки вместо обычного каталога .git/hooks. Это та часть, которую вы можете применять.

Другая часть зависит от доброй воли разработчика. Чтобы установить папку хуков как hooksPath, каждый разработчик должен запустить:

git config core.hooksPath hooks

Теперь все хуки в папке хуков будут работать так, как вы ожидаете.

Ответ 5

Предполагая, что у вас есть исходный код в вашем репозитории git, у которого есть связанная с ним система сборки, вы можете настроить систему сборки для настройки крюка предварительной фиксации, то есть путем перемещения или связывания крюка предварительной фиксации, который ~ версии.

Я еще не пробовал. Я пришел сюда, когда искал поисковую систему для лучшего решения.

Ответ 6

Я создаю новый файл: pre-commit-hook.sh

#!/usr/bin/env bash
CHANGES=$(git whatchanged ..origin)

if [ ! -z "${CHANGES}" ]; then
    echo "There are changes in remote repository. Please pull from remote branch first."
    exit 1;
fi

exit 0;

И вот как я обязуюсь Git:

bash pre-commit-hook.sh && git commit -m "<Commit message>"