TFS и Git — ограничение пользователям push-кода

Мы используем TFS в качестве интерфейса управления проектами и используем Git для управления репозиторием.

Мы хотим, чтобы пользователи были ограничены в отправке файла и отправке ветки в репозиторий.

Например: В ветке A пользователь 1 не может вносить изменения в файл 1, пользователь 2 не может вносить изменения в файл 2, пользователь 3 может вносить изменения во все файлы в ветке и т. д.

Возможно ли это в TFS?


person Görkem Özer    schedule 16.06.2017    source источник
comment
мы не можем точно установить ограничение, как вы упомянули, мы можем только установить соответствующее разрешение на основе существующих настроек, см. аналогичную ветку stackoverflow.com/questions/27989974/   -  person Andy Li-MSFT    schedule 16.06.2017


Ответы (2)


Возможно ли это в TFS?

Не то чтобы я знаю.

Что вы можете сделать, так это настроить промежуточный репозиторий, который будет действовать как привратник: если отправка будет успешной, это репо (через хук post-receive) отправит на фактическую цель: репозиторий TFS Git.

Этим промежуточным репо должен управлять уровень авторизации, такой как gitolite: gitolite может ограничить отправку ветки или даже файла: см. "ограничение отправки по имени каталога/файла"

person VonC    schedule 16.06.2017

Я вижу, что вы делаете это только через сервер TFS- дополнительный плагин. Вы можете реализовать ISubscriber, который подписывается на Git PushNotification событие. Это позволит вам проверить отправленные коммиты и заблокировать их, если ваши политики не будут удовлетворены. Однако вам нужно будет определить ограничения вашей ветки/пользователя в каком-то структурированном формате за пределами TFS.

Я успешно использовал этот проект, который обеспечивает хорошую основу для реализации политик при отправке сообщений в репозиторий Git, размещенный на TFS:

https://github.com/giuliov/GitPushFilterPlugin

Единственное предостережение (из моего собственного опыта) заключается в том, что объема данных, доступных в событии PushNotification, может быть недостаточно для определения того, какие ветки IncludedCommits относится к.

person Pero P.    schedule 20.06.2017