This is an in-progress translation.
To help translate the book, please fork the book at GitHub and push your contributions.

Gitolite

Git начал становиться очень популярным в корпоративных средах, где обычно есть дополнительные требования в плане контроля доступа. Gitolite изначально был создан, чтобы посодействовать в выполнении таких требований. Но, как оказывается, он также полезен и в мире open source: проект Fedora управляет доступом к своим репозиториям пакетов с помощью Gitolite’а. А ведь этих репозиториев больше 10 000! По видимому, это самая большая установка Gitolite’а где бы то ни было.

Gitolite позволяет указать права доступа не только для репозиториев, но и для веток или имён меток внутри каждого репозитория. То есть вы можете указать, что определённые люди (или группы людей) могут отправлять (push) определённые “ссылки” (ветки или метки), а остальные нет.

Установка

Установить Gitolite очень просто, даже если вы не читали обширную документацию, которая идёт вместе с ним. Вам нужен аккаунт на каком-нибудь Unix-сервере; были протестированы различные Linux’ы и Solaris 10. Вам не нужен root-доступ, если git-, perl- и openssh-совместимый сервер уже настроены. Далее в примерах мы будем использовать аккаунт gitolite на хосте с именем gitserver.

Gitolite несколько необычен, по крайней мере, в сравнении с другим “серверным” ПО — доступ осуществляется по ssh, и, следовательно, каждый пользователь на сервере является потенциальным “gitolite-хостом”. Поэтому всё выглядит как “установка” самого ПО и затем “настройка” пользователя как “gitolite-хоста”.

Gitolite может быть установлен четырьмя способами. Люди, использующие Fedora’у или Debian, могут получить RPM или DEB и установить его. Те, у кого есть root-доступ, могут сделать установку вручную. В обоих вариантах любой пользователь в системе затем может стать “gitolite-хостом”.

Те, у кого нет root-доступа, могут установить его внутрь своих каталогов. И наконец, gitolite может быть установлен с помощью выполнения сценария на рабочей станции в bash-шелле. (Если вам интересно, даже тот bash, который идёт с msysgit, достаточен.)

Последний способ мы опишем в этой статье; а остальные методы описаны в документации.

Начните с настройки доступа к вашему серверу по открытому ключу, так, чтобы вы могли войти с вашей рабочей станции на сервер без ввода пароля. Следующий способ работает в Linux’е; для рабочих станций с другими ОС вам, возможно, нужно будет сделать это вручную. Мы полагаем, что у вас уже есть пара ключей сгенерированных с помощью ssh-keygen.

$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver

Эта команда спросит у вас пароль к учётной записи ‘gitolite’, а затем настроит доступ по открытому ключу. Он необходим для сценария установки, так что убедитесь, что вы можете выполнять команды без ввода пароля:

$ ssh gitolite@gitserver pwd
/home/gitolite

Затем склонируйте Gitolite с главного сайта проекта и выполните сценарий для лёгкой установки (третий аргумент это ваше имя в том виде, в котором вам бы хотелось его видеть в окончательном репозитории gitolite-admin):

$ git clone git://github.com/sitaramc/gitolite
$ cd gitolite/src
$ ./gl-easy-install -q gitolite gitserver sitaram

Всё готово! Gitolite теперь установлен на сервере, и у вас в домашнем каталоге на рабочей станции теперь есть новый репозиторий, который называется gitolite-admin. Администрирование вашего установленного Gitolite’а осуществляется с помощью внесения изменений в этот репозиторий и их отправки (push).

Та последняя команда выводит довольно большое количество информации, которую может быть интересно прочитать. Также при первом её выполнении создаётся новая пара ключей; вам придётся выбрать пароль или нажать enter, чтобы пароля не было. Зачем нужна вторая пара ключей и как она используется, описано в документе “ssh troubleshooting”, поставляемом с Gitolite’ом. (Ну должна же документация быть хоть для чего-то хороша!)

По умолчанию на сервере создаются репозитории с именами gitolite-admin и testing. Если вы хотите получить локальную копию какого-то из них, наберите (под учётной записью, которая имеет консольный SSH-доступ к Gitolite-аккаунту в authorized_keys):

$ git clone gitolite:gitolite-admin
$ git clone gitolite:testing

Чтобы склонировать эти же самые репозитории под любым другим аккаунтом:

$ git clone gitolite@servername:gitolite-admin
$ git clone gitolite@servername:testing

Изменение параметров установки

Хотя быстрая установка с параметрами по умолчанию подходит для большинства людей, есть несколько способов изменения параметров установки если вам это нужно. Если опустить опцию -q, вы получите “подробную” установку с детальной информацией о том, что происходит на каждом шаге. Подробный режим также позволяет изменить некоторые параметры на стороне сервера, такие как расположение репозиториев, с помощью редактирования “rc” файла, используемого сервером. Этот “rc” файл содержит развёрнутые комментарии так, чтобы вы легко смогли сделать любые изменения, сохранить их и продолжить. Этот файл также содержит различные настройки, которые вы можете изменить, чтобы активировать или выключить некоторые “продвинутые” функции Gitolite’а.

Конфигурационный файл и правила контроля доступа

Когда установка завершена, вы переходите в репозиторий gitolite-admin (он находится в вашем домашнем каталоге) и осматриваетесь, чтобы выяснить что же вы получили:

$ cd ~/gitolite-admin/
$ ls
conf/  keydir/
$ find conf keydir -type f
conf/gitolite.conf
keydir/sitaram.pub
$ cat conf/gitolite.conf
#gitolite conf
# please see conf/example.conf for details on syntax and features

repo gitolite-admin
    RW+                 = sitaram

repo testing
    RW+                 = @all

Заметьте, что “sitaram” (это последний аргумент при выполнении gl-easy-install ранее) имеет права на чтение и запись в репозиторий gitolite-admin, а также файл с открытым ключом с таким же именем.

Синтаксис конфигурационного файла для Gitolite’а подробно продокументирован в conf/example.conf, так что мы рассмотрим здесь только основные моменты.

Вы можете сгруппировать пользователей или репозитории для удобства. Имена групп совсем как макросы; когда вы их определяете, даже неважно, определяют ли они проекты или пользователей; это различие делается, только когда вы используете “макрос”.

@oss_repos      = linux perl rakudo git gitolite
@secret_repos   = fenestra pear

@admins         = scott     # Adams, not Chacon, sorry :)
@interns        = ashok     # get the spelling right, Scott!
@engineers      = sitaram dilbert wally alice
@staff          = @admins @engineers @interns

Вы можете контролировать права доступа на уровне “ссылок” (то, что находится в .git/refs/). В следующем примере стажёры (группа @interns) могут отправлять (push) только ветку “int”. Инженеры (группа @engineers) могут отправлять любую ветку, чьё имя начинается с “eng-“, а также метки, начинающиеся с “rc” и затем содержащие цифры. Администраторы (группа @admins) могут делать всё с любыми ссылками (в том числе откатывать назад).

repo @oss_repos
    RW  int$                = @interns
    RW  eng-                = @engineers
    RW  refs/tags/rc[0-9]   = @engineers
    RW+                     = @admins

Выражение после RW или RW+ — это регулярное выражение (regex), с которым сопоставляется имя отправляемой ссылки (ref). Поэтому мы называем его “refex”! Конечно, “refex” может быть гораздо более сложным, чем показано здесь, так что не переусердствуйте с ними, если вы не очень хорошо знакомы с регулярными выражениями Perl.

К тому же, как вы уже, наверное, догадались, Gitolite для удобства дописывает в начале регулярного выражения refs/heads/, если оно не начинается с refs/.

Важной особенностью синтаксиса конфигурационного файла является то, что все правила для репозитория не обязательно должны находиться в одном месте. Вы можете держать все общие вещи вместе, как, например, правила для всех oss_repos выше, а потом добавить уточняющие правила для отдельных случаев следующим образом:

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” и некоторых других.

Логирование: Gitolite регистрирует все успешные действия. Если вы несколько легкомысленно раздали людям права на откатывание изменений (RW+) и кто-то снёс “master”, лог-файл спасёт вам жизнь, и вы легко и быстро найдёте потерянный SHA.

Git не в обычном PATH: Одна крайне полезная и удобная функция в Gitolite’е — это поддержка Git’а, установленного вне обычного $PATH (это совсем не такая редкость, как вы думаете; в некоторых корпоративных средах или даже у некоторых хостинг-провайдеров запрещается устанавливать что-либо в систему, и всё заканчивается тем, что вы кладёте всё в свои личные каталоги). Обычно вы вынуждены каким-то образом заставить Git на стороне клиента учитывать это нестандартное расположение бинарников Git’а. С Gitolite’ом просто выберите “подробную” установку и задайте $GIT_PATH в “rc” файлах. Никаких изменений на стороне клиента после этого не требуется.

Уведомление о правах доступа: Другая удобная функция проявляется в момент, когда вы просто проверяете и заходите по ssh на сервер. Gitolite показывает, к каким репозиториям у вас есть доступ и какого типа доступ может быть получен. Вот пример:

    hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
    the gitolite config gives you the following access:
         R     anu-wsd
         R     entrans
         R  W  git-notes
         R  W  gitolite
         R  W  gitolite-admin
         R     indic_web_input
         R     shreelipi_converter

Делегирование: При действительно больших установках вы можете делегировать ответственность за группы репозиториев различным людям, которые будут независимо управлять этими частями. Это уменьшает нагрузку на главного админа и делает его не таким критичным элементом. Эта функция описана в отдельном файле в каталоге doc/.

Поддержка GitWeb: Gitolite имеет поддержку GitWeb в нескольких аспектах. Вы можете указать, какие репозитории видны через GitWeb. Вы можете назначить “владельца” и “описание” для GitWeb из конфигурационного файла для Gitolite’а. В GitWeb есть механизм организации контроля доступа через аутентификацию по HTTP, и вы можете заставить его использовать “скомпилированный” конфигурационный файл, сделанный Gitolite’ом, что означает действие одинаковых правил контроля доступа (для доступа на чтение) и для GitWeb, и для Gitolite’а.

Зеркалирование: Gitolite может помочь вам поддерживать несколько зеркал, и легко переключаться между ними, если основной сервер упадёт.