Использование хуков обновления

Вы знаете о хуках - прочтите, пожалуйста, о них документация ! Хук, который вам, вероятно, нужен, - это update, который запускается один раз для каждой ссылки. (Ловушка предварительного приема запускается один раз за все нажатие) На SO уже есть множество вопросов и ответов об этих хуках; в зависимости от того, что вы хотите сделать, вы, вероятно, сможете найти руководство о том, как написать ловушку, если она вам понадобится.

Чтобы подчеркнуть, что это действительно возможно, цитата из документации:

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

Его также можно использовать для регистрации старого… нового статуса.

И особенности:

Ловушка выполняется один раз для каждой обновляемой ссылки и принимает три параметра:

• имя обновляемой ссылки,
• старое имя объекта, хранящееся в ссылке,
• и новое имя объекта, которое будет сохранено в исх.

Так, например, если вы хотите убедиться, что ни одна из тем фиксации не превышает 80 символов, очень примитивной реализацией будет:

#!/bin/bash
long_subject=$(git log --pretty=%s $2..$3 | egrep -m 1 '.{81}')
if [ -n "$long_subject" ]; then
    echo "error: commit subject over 80 characters:"
    echo "    $long_subject"
    exit 1
fi

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

Зачем нужна ловушка обновления

Это обсуждалось / разъяснялось в комментариях; вот резюме.

Ловушка обновления запускается один раз для каждой ссылки.Ссылка - это указатель на объект; в данном случае мы говорим о ветвях и тегах и, как правило, просто о ветвях (люди не часто нажимают теги, поскольку они обычно используются только для маркировки версий).

Теперь, если пользователь отправляет обновления в две ветки, основную и экспериментальную:

o - o - o (origin/master) - o - X - o - o (master)
 \
  o - o (origin/experimental) - o - o (experimental)

Предположим, что X является «плохой» фиксацией, то есть той, которая не удала бы перехватчик commit-msg. Ясно, что мы не хотим соглашаться с тем, чтобы стать мастером. Итак, ловушка обновления отклоняет это. Но в экспериментальных коммитах нет ничего плохого! Ловушка обновления принимает это. Следовательно, origin / master остается неизменным, но origin / экспериментальный обновляется:

o - o - o (origin/master) - o - X - o - o (master)
 \
  o - o - o - o (origin/experimental, experimental)

Ловушка pre-receive запускается только один раз, непосредственно перед началом обновления ссылок (перед первым запуском ловушки update). Если бы вы использовали его, вам пришлось бы вызвать сбой всего push, таким образом говоря, что из-за плохого сообщения о фиксации на мастере вы почему-то больше не верите, что фиксации на экспериментальном уровне хороши, даже если их сообщения в порядке!