GIT-хук, чтобы предотвратить переход экспериментальной ветви в релиз или мастер-ветку

У нас есть три основных ветви в нашем рабочем процессе.

TEST (экспериментальный), RELEASE (функции будут доступны в следующем выпуске) и MASTER (выпущен только)

Мы берем ветви функций из RELEASE, сначала объединяем ветви функций с TEST, а если они в порядке, объединяем эти одобренные ветви функций с RELEASE.

Моя проблема: поскольку ветка TEST содержит некоторые коммиты / функции, которые мы никогда не будем выпускать, мы не хотим, чтобы они сливались в RELEASE или MASTER по ошибке (или намеренно).

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

Поэтому, вероятно, лучше предотвратить обновления ссылок веток MASTER или RELEASE в главном репозитории (путем нажатия на источник), когда новая ссылка содержит определенный идентификатор фиксации ветви TEST в своем журнале фиксации.

Поэтому я сделаю конкретный коммит только для ветки TEST и запишу его коммит ID.

Всякий раз, когда кто-то хочет нажать на ветку master или release, я проверю, будет ли этот push обновлять мои refs/ заголовки /master или refs/heads/RELEASE до ref-фиксации, который содержит этот неверный идентификатор фиксации в своей истории и отменяется.

Поскольку я не являюсь мастером BASH или GIT, есть ли у кого-нибудь такая ловушка обновления, которую мы можем применить к нашему основному репозиторию?

Источник

2 ответа

Решение

Вот хук обновления, который должен работать для этого. Вы можете указать коммиты, которые не должны быть разрешены в вашей ветке RELEASE или MASTER, присваивая им такие теги, как forbidden/junk или же forbidden/debugging, Если найден запрещенный коммит, имя тега будет включено в сообщение об отказе.

refname="$1"
oldrev="$2"
newrev="$3"
case "$refname" in
  refs/heads/RELEASE|refs/heads/MASTER)
    for forbidden in $(git tag -l 'forbidden/*'); do
      if [ $(git merge-base "$forbidden" $newrev) = $(git rev-parse "$forbidden") ]; then
        echo "Push to $refname contains commit $forbidden" >&2
        exit 1
      fi
    done
    ;;
esac
exit 0

Обратите внимание, что если у вас есть ветка, содержащая несколько проблемных коммитов, вы должны создать forbidden тег для самого раннего, а не только для последнего коммита в серии. Так что, если история, как следующий, где B,C, а также D все запрещено только пометка D как запрещено не помешает E от слияния и принесения B вместе с этим.

A---B----C----D
     \
      ---E
Источник

Эта проблема должна решаться как проблема управления, а не как проблема автоматизации. Проблема в том, что TEST, вероятно, содержит большинство коммитов из двух других веток. Таким образом, вы не сможете эффективно идентифицировать коммиты, пришедшие из TEST. Например, в нашей среде мы регулярно обновляем экспериментальные ветки новыми коммитами из основной ветки.

Вам нужен кто-то, чтобы действовать в качестве менеджера релизов, чтобы гарантировать, что если что-то плохое действительно будет объединено с мастером, то оно не будет развернуто до того, как проблема будет решена. Проблема не обязательно в плохом слиянии. Проблема развертывания неудачного слияния.

Один из инструментов, который вы можете найти полезным, находится на https://bitbucket.org/, где у них есть элементарный механизм утверждения для фиксации. Это только рекомендация, но она может быть полезна для вас, чтобы отследить, какие коммиты были одобрены, а какие могли быть добавлены по ошибке.

Источник
Другие вопросы по тегам