Можно ли избежать «git push» ветки к УДАЛЕННОМУ источнику, если были выполнены какие-либо коммиты?

#git #push #githooks #git-push

#мерзавец #толкать #githooks #git-толчок

Вопрос:

Мне понадобится крючок, который проверяет git push работу.

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

В принципе, я хочу избежать этой ситуации

 $ (master) git checkout -b ticket-abc master

$ (ticket-abc) git push origin ticket-abc
 

Я хотел бы заблокировать эту вторую строку, если нет коммитов, связанных с этой новой веткой. Есть ли способ справиться с этим с помощью git-хуков?

Большое спасибо

Комментарии:

1. Что вы имеете в виду подтолкнуть ветку к источнику? Вы имеете в виду слияние?

2. Я отредактировал вопрос

3. Какого эффекта вы хотите избежать? Операция, которую вы описываете, не имеет никакого эффекта, поскольку новая ссылка такая же, как и старая. На удаленном компьютере ничего не будет изменено, и локально выводится «Все обновленное».

4. что ж, новая ветка передается в origin с именем ticket-abc в remotes. Мне нужно избегать отправки веток на remotes — origin, которые идентичны master, поэтому перед любыми выполненными коммит.

5. Итак, вы не хотите создавать новую ветку, если они не приносят никаких новых коммитов. Но я все еще не понимаю смысла… это настолько частая ситуация, что она загромождает ваш пульт? Разве эти новые ветки в конечном итоге не обновляются с помощью коммитов? Разве у вас нет повторяющейся процедуры очистки для ветвей? Извините за все вопросы 🙂

Ответ №1:

Перехват pre-push может быть принят.

 #!/bin/bash

master_sha=$(git rev-parse refs/heads/master)
while read local_ref local_sha remote_ref remote_sha;do
    if [[ "${local_sha}" = "${master_sha}" ]];then
        echo error: ${local_ref} points at the same commit with master
        echo error: push failed
        exit 1
    fi        
done
exit 0
 

Но я немного обеспокоен стабильностью местных master жителей . Если он случайно обновляется, хук не может обнаружить его изменение и, следовательно, не может выполнить push, как ожидалось.

Комментарии:

1. Можете ли вы лучше определить «для случайного обновления»? что вы имеете в виду?

2. foo создается на основе master и master обновляется с помощью git pull , git commit , или других команд, которые переходят master к новой фиксации до foo ее нажатия.

3. Я должен сказать, что в моем сценарии толчок был сделан, так что крюк не сработал

4. @axel Вызывается ли перехват? Каковы значения ${local_sha} и ${master_sha} ?

Ответ №2:

Я бы выбрал update серверный хук:

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

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

Тогда я бы сделал что-то вроде этого:

 #!/bin/sh

refname="$1"
oldrev="$2"
newrev="$3"

master=$(git rev-parse refs/heads/master)

if [ "$newrev" = "$master" ]; then
    echo "Rejected: $refname has no new commits compared to master" >amp;2
    exit 1
fi

exit 0
 

Здесь мы просто сравниваем SHA-1 коммита ( newrev ), на который ссылается ветвь, на которую нажимается ( refname ), с SHA-1 коммита, на который ссылается master . Если они равны, мы завершаем работу с кодом ошибки, тем самым предотвращая создание этой конкретной ветки на сервере.

Из документации:

Непосредственно перед обновлением ссылки в удаленном репозитории вызывается перехват обновления. Его статус выхода определяет успех или неудачу обновления ссылки.

Комментарии:

1. Я должен сказать, что в моем сценарии толчок был сделан, так что крюк не сработал

2. Этот перехват выполняется на сервере, поэтому, естественно, он реагирует на push выполняемую операцию. Однако это остановит создание ветки на удаленном компьютере.