2016-04-28 2 views
1

Мы недавно изменили имя feature от foo до bar. Это хорошая возможность создать новый филиал не позднее master, из которого будет продолжаться работа.Как запретить разработчикам нажимать на определенную ветку?

Предыдущая ветка должна храниться для ее истории, и я не могу ее удалить.

Поэтому я хотел бы найти механизм, препятствующий запутанным разработчикам вносить изменения в неправильную ветку. Моя хитрость заключается в:

$ git checkout feature/foo 
$ git commit --allow-empty -m "WARNING: DO NOT COMMIT on this branch" 
$ git push 

К сожалению, я предпочел бы решение, как

$ git branch --lock feature/foo -m "Use feature/bar instead" 
$ git push 

Что другой вариант я мог бы использовать?

Примечание: Я также могу переименовать текущую ветку git branch -m feature/foo feature/bar, но это не в тему.

+2

'Предыдущая ветвь должна быть сохранена для ее истории, и я не могу ее удалить. 'Вы можете удалить ветку и создать тег с тем же именем. – AD7six

+0

О! Это очень хороший момент. – nowox

+0

Использование тега - довольно приличный трюк. Заметьте, однако, что старые версии git (примерно до 1.8.something) позволяют толкать теги перемотки вперед, т. Е. Обрабатывать их точно так же, как ветви. (Хотя вы не можете проверить их, как ветви, так что вы получите там честную безопасность). – torek

ответ

1

Это то, что предназначены для предварительного приема и обновления крючков.

Создание такого крючка на сервере требует доступа к серверу. Вы не упоминаете, является ли это вашим собственным сервером или каким-либо поставщиком услуг git as a service (GaaS?). У поставщиков всегда есть свои частные методы определения перехвата, поскольку по соображениям безопасности они не дают вам полного доступа к серверу.

Если это ваш собственный частный сервер, создайте крючок на любом языке, который вам нравится. Проверьте, не изменилось ли изменение входящего задания (в pre-receive) или запрошенное изменение ссылки (в update) для филиала feature/foo. Если это так, напечатайте сообщение об ошибке для пользователя: эта ошибка будет скопирована на их машину с префиксом remote:.

#! /bin/sh 
status=0 
while read oldsha newsha refname; do 
    case $refname in 
    refs/heads/feature/foo) 
     echo "branch feature/foo is deprecated, use feature/bar" 1>&2 
     status=1 
     ;; 
    esac 
done 
exit $status 

(пример pre-receive10 крюк).

Обратите внимание, что с помощью предварительно получить крючок, отказ будет отвергать все толчок, то есть, если я пытался подтолкнуть как feature/foo и personal/blah, я хотел бы видеть:

remote: branch feature/foo is deprecated, use feature/bar 

и мои подтолкну fail, с personal/blah не обновляется.

Используя update крюк, мой толчок бы наполовину неудачу и наполовину успеха: я хотел бы видеть то же сообщение об ошибке и feature/foo не получить толкнул, но personal/blah бы.

+0

Проклятый, я бы упомянул об этом: мы не используем сервер, кроме голой репозиториев где-то в сети. (Это займет много времени, чтобы убедить нашего руководства, что сервер Git может быть полезен для чего-то) – nowox

+0

Но это хорошее решение кстати. – nowox

+1

«Голые репозитории где-то в сети» = «где-то» - ваш сервер! (Хотя, если он просто представлен как файловая система или сетевой диск, вы немного застреваете, то не будет задействовать крючки.) – torek

1

Это похоже на то, что вы хотели бы использовать git hooks for. pre-push hook может довольно легко указать такое ограничение.

В папке .git/hooks создайте сценарий под названием pre-push. Содержимое должно быть Bash-скриптом, который возвращает 1, если вы хотите предотвратить нажатие.Моя первая идея этого вдоль этих линий:

#!/bin/bash 
locked_branch='feature/foo' 
push_branch=$(git rev-parse --abbrev-ref HEAD) 

if [ "$locked_branch" = "$push_branch" ] 
then 
    echo "Do not push this branch! Use feature/bar instead" 
    exit 1 
fi 
exit 0 

EDIT:

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

if [ "$locked_branch" = "$1" ] 

вместо того, чтобы иметь push_branch переменные, на основе первого сценария, публикуемый.

+1

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

+0

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

Смежные вопросы