Git запрещает пользователям создавать теги

Question

Вот вопрос об управлении git-репо ...

Можно ли настроить git repo для разрешения создания TAG только для некоторых пользователей? И аналогичный вопрос для ветки: можно ли настроить список пользователей, которые могут изменять конкретную ветку?

Идея для всего этого конфига такова: есть git repo с МНОГИМИ разработчиками, и мы хотим иметь несколько стабильных веток и список тегов. И только старшие разработчики смогут изменять эти ветки и создавать теги. Все остальные разработчики все еще могут создавать ветки и так далее. Но если разработчик хочет продвигать свои изменения в одной из стабильных веток, он должен связаться со старшим человеком, чтобы попросить его сделать слияние ...

спасибо

Answer 1

Gerrit (в основном система проверки кода) решает эту проблему почти точно так, как вы ее описываете.

Вы определяете группы, а затем задаете разрешения репозитория для тех, кто может подавать заявку на проверку.в ветке, который может отправлять изменения непосредственно в ветку, кто может толкать теги (различных типов) и даже кто может видеть / толкать вашу сверхсекретную ветвь.

Наш экземпляр Gerrit открыт для всего мира, хотя мы действительно ограничиваем, кто может что и куда подталкивать (и у нас есть соавторы в одних проектах, которые могут делать больше, чем другие).

Answer 2

Для ветвей и аннотированных тегов (т. Е. Версионных тегов, которые можно вставлять / извлекать), gitolite может обеспечить такой тип контроля доступа.

См. " совпадение с реф и рексом " (gitolite 3.x)

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

Если ссылка не указана, по умолчанию используется refs/.*, например, в таком правиле:

RW              =   alice

Рефекс, не начинающийся с refs/ (или VREF/), должен начинаться с refs/heads/.
Это означает, что обычные ветки можно написать так:

RW  master      =   alice
# becomes 'refs/heads/master' internally

, в то время как теги должны быть полностью квалифицированы:

RW  refs/tags/v[0-9]    =   bob

---

Таким образом, по умолчанию вы не можете выдвигать теги, если нет явного правила refs/tag/, разрешающего его для вашего пользователя или группы пользователей.

Answer 3

Вы можете ограничить доступ, используя стандартные правила доступа к файлам в .git / refs /heads и .git / refs / tags.Например, если вы используете режим .git / refs / tags 775, то только члены группы, которой принадлежат .git / refs / tags, смогут создавать теги.Аналогично, вы можете ограничить разрешение на чтение для .git / refs /head / foo, чтобы только те, у кого есть права на чтение, могли извлекать ветку foo, и только те, у кого есть доступ для записи в .git / refs /head, смогут создаватьветви.Однако это ненадежный метод, и вам будет гораздо лучше использовать отдельные репозитории с соответствующими правами доступа.

Answer 4

Насколько я понимаю, читая документацию и личный опыт, Git не предназначен для такого использования.То, что вы описываете, может быть легко обработано сценарием с несколькими репозиториями, в котором меньшие разработчики продвигаются в репозиторий разработки, а старшие разработчики извлекают из этого изменения, объединяют, тестируют и т. Д., А затем развертывают в производственном репозитории, из которого любойразработчик может тянуть.