Как предотвратить слияние определенной ветви в git? - PullRequest
Новая
       15

Как предотвратить слияние определенной ветви в git?

0 голосов
/ 24 октября 2018

У нас есть ветвь master, в которой живет выпущенный производственный код, ветвь dev, в которой живет код для тестового сервера, и различные ветви функций (разветвленные от master), по желанию каждого разработчика.

Со временем ветвь dev несколько отклонилась от master.Кроме того, там есть некоторые неправильные слияния, которые портят части кода.Уже несколько раз мы пытались сбросить (принудительное нажатие) dev так же, как master.Начать все с чистого листа, так сказать.

К сожалению, это не длится долго.Рано или поздно кто-то сливает старый dev в новый dev, возвращая ему всю путаницу.Я подозреваю, что это может даже произойти автоматически, когда наивный git pull молча объединяет старые и новые заголовки веток.

Можно ли предотвратить это с помощью ловушки фиксации на стороне сервера?Что-то, что откажется принять git push, если в него будет вставлен неправильный коммит?

Ответы [ 3 ]

0 голосов
/ 24 октября 2018

Это возможно с Git Hooks .Поместите следующий POC-скрипт в .git/hooks/pre-receive в своем удаленном (серверном) хранилище и дайте ему право на выполнение.

Настройте ветвь, которую вы хотите защитить, например master

$ git config hooks.protected-branch.refs master

Файл: .git / hooks / pre-receive 

#!/bin/sh

read old_value new_value ref_name

refs=$(git config hooks.protected-branch.refs)

for ref in $refs; do
    if [ "$ref_name" == "refs/heads/$ref" ]; then
        if [ "$old_value" == "0000000000000000000000000000000000000000" ]; then
            continue
        fi

        if ! git merge-base --is-ancestor "$ref_name" "$new_value"; then
            echo "$ref_name is protected branch"
            exit 1
        fi
    fi
done

Когда вы попытаетесь сбросить master принудительным нажатием, вы получите похожий вывод: 

Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (12/12), 920 bytes | 153.00 KiB/s, done.
Total 12 (delta 4), reused 0 (delta 0)
remote: refs/heads/master is protected branch
To ../demo
 ! [remote rejected]   master -> master (pre-receive hook declined)
error: failed to push some refs to '../demo
0 голосов
/ 31 декабря 2018

Рано или поздно кто-то объединяет старого разработчика с новым, возвращая ему весь беспорядок.

Это распространенная проблема при использовании поведения по умолчанию git pull.Чтобы избежать этого, можно настроить git pull на использование rebase по умолчанию вместо merge.То есть, чтобы переместить текущую ветку в удаленную ветку вместо ее слияния:

git config pull.rebase interactive

со страницы руководства git-config:

pull.rebase

Когда true, перебазировать ветви поверх извлеченной ветви вместо слияния ветви по умолчанию с удаленного по умолчанию при запуске «git pull».См. "Branch..rebase" для установки этого параметра для каждой ветви.

Когда preserve, также передайте --preserve-merges вместе с git rebase, чтобы локально зафиксированные коммиты слияния не были сглаженыrunning git pull.

Когда значение равно interactive, перебазирование выполняется в интерактивном режиме.

ПРИМЕЧАНИЕ: это возможно опасная операция;не используйте его, пока вы не поймете последствия (подробнее см. git-rebase (1)).

При этом всякий раз, когда удаленная ветвь перезаписывается (с push -f), кто бы ни тянулотвечает за выявление и удаление «старых» коммитов во время ребазинга.Это приводит к чистой истории (то есть: без слияния «старых» версий) в каждой ветви.

0 голосов
/ 24 октября 2018

GitHub имеет функцию, называемую защищенными ветвями, которая дает администраторам хранилища возможность отключать принудительные нажатия на определенные ветви.

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

для получения дополнительной информации ... Пожалуйста, проверьте https://blog.github.com/2015-09-03-protected-branches-and-required-status-checks/

...