repo gitolite RW+ = sitaram
Это правило будет добавлено к набору правил для репозитория gitolite.
В данный момент вы, возможно, задаётесь вопросом: "Каким образом правила контроля доступа применяются на самом деле?" — так что давайте вкратце рассмотрим это.
В gitolite есть два уровня контроля доступа. Первый — на уровне репозитория; если у вас есть доступ на чтение (или запись) к любой ссылке в репозитории, то у вас есть доступ на чтение (или запись) к этому репозиторию.
Второй уровень применим только к доступу на запись и осуществляется по веткам или меткам внутри репозитория. Имя пользователя, запрашиваемый уровень доступа (W или +) и имя ссылки, которая будет обновлена, известны. Правила доступа проверяются в порядке их появления в конфигурационном файле, в поисках совпадений для этой комбинации (но помните, что имя ссылки сопоставляется с регулярным выражением, а не просто строкой). Если совпадение найдено, отправка (push) проходит успешно. При неудачном исходе доступ запрещается.
Продвинутый контроль доступа с запрещающими правилами
До сих пор у нас были только права вида R, RW, или RW+. Однако, в gitolite есть другие права доступа: - означающий "запретить". Это даёт гораздо больше возможностей взамен большей сложности, так как теперь отсутствие разрешающего правила — не единственный способ получить запрет доступа, так что порядок правил теперь имеет значение!
Предположим, в описанной выше ситуации мы хотим, чтобы инженеры могли откатить назад любую ветку кроме master и integ. Вот как это сделать:
RW master integ = @engineers - master integ = @engineers RW+ = @engineers
Снова, вы просто идёте по правилам сверху вниз, пока не наткнётесь на соответствующее вашему режиму доступа или на запрет. Неоткатывающий push в master или integ разрешается первым правилом. Откатывающий push для этих ссылок не соответствует первому правилу, переходит ко второму и поэтому запрещается. Любой push (откатывающий или неоткатывающий) по ссылкам, отличным от master и integ, не совпадёт с первыми двумя правилами, а третье правило его разрешает.
Ограничение push-ей на основе изменённых файлов
Вдобавок к ограничению веток, в которые пользователю можно отправлять изменения, вы можете также ограничить файлы, которые он может трогать. Например, возможно, Makefile (или какая-то другая программа) не предназначен для изменения кем угодно, так как многие вещи зависят от него или сломаются, если изменения не будут сделаны правильно. Вы можете сказать gitolite-у:
repo foo RW = @junior_devs @senior_devs RW NAME/ = @senior_devs - NAME/Makefile = @junior_devs RW NAME/ = @junior_devs
Это мощное средство продокументировано в conf/example.conf.
Персональные ветки
Gitolite также имеет средство, которое называется "персональные ветки" (или даже "персональное пространство имён веток"), которое может быть весьма полезным в корпоративных средах.
Очень часто обмен кодом в мире git происходит через запросы "пожалуйста, заберите (pull)". В корпоративных средах, однако, неаутентифицированный доступ под строгим запретом, и рабочая станция разработчика не может выполнить аутентификацию. Так что вы вынуждены отправить (push) работу на центральный сервер и попросить кого-нибудь забрать (pull) её оттуда.
Это обычно вызывает такой же беспорядок с именами веток, что и в централизованных СУВ, плюс настройка прав доступа для этого становится ежедневной обязанностью админа.
Gitolite позволяет определить "персональный" или "рабочий" префикс пространства имён для каждого разработчика (например, refs/personal/<devname>/*); подробное описание есть в разделе "personal branches" в doc/3-faq-tips-etc.mkd.
"Шаблонные" репозитории
Gitolite позволяет указывать репозитории с помощью шаблонов (на самом деле регулярных выражений perl), таких как, например, assignments/s[0-9][0-9]/a[0-9][0-9]. Это очень мощная функция, которая включается с помощью установки $GL_WILDREPOS = 1; в rc файле. Она позволяет назначать новый режим доступа ("C"), который позволяет пользователям создавать репозитории на основе подобных шаблонов, автоматически назначает владельцем пользователя, который создал репозиторий, позволяет ему раздавать R и RW права другим пользователям и т.п. Эта функция описана в документе doc/4-wildcard-repositories.mkd.
Другие функции
Мы закончим это обсуждение рассмотрением подборки других функций, все они и многие другие описаны в мельчайших подробностях в документе "faqs, tips, etc" и некоторых других.