gitolite — это средство для создания централизованных репозиториев для совместной разработки через git.
 Зачем оно нужно?
Родные средства git для этой задачи на сегодня явно недостаточны: родной git-протокол не содержит каких-либо средств авторизации, а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.
gitolite же позволит вам заводить пользователей независимо от наличия аккаунта в ОС и гибко раздавать права.
gitolite — это средство для создания централизованных репозиториев для совместной разработки через git.

Зачем оно нужно?

Родные средства git для этой задачи на сегодня явно недостаточны: родной git-протокол не содержит каких-либо средств авторизации, а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.
gitolite же позволит вам заводить пользователей независимо от наличия аккаунта в ОС и гибко раздавать права.

Пресуппозиции

• Тема большая. Следовательно, описаны далеко не все возможности.
• В своей документации разработчик gitolite ссылается на огромное количество проблем, которые возникают от недостаточного понимания принципов работы с ssh с аутентификацией через публичные ключи. Поэтому если вы несколько «плаваете» в этом вопросе — в конце статьи есть небольшое howto.
• В статье подразумевается, что сервер, предназначенный для установки gitolite, работает на unix-like системе

Установка

На самом деле в большинстве случаев установка не вызывает каких-либо вопросов.
На сервере:

• Заводим в системе нового пользователя. Для удобства назовем его git.
• Копируем публичный ключ пользователя, который будет администратором, в домашнюю папку пользователя git. Обратите внимание, что имя ключа должны быть формата .pub, где — это то, как вас будет знать gitolite. Это имя может не совпадать с каким-либо системным. Если мы хотим, чтобы gitolite знал нас как gitadmin, то файл с ключем должен быть переименован в gitadmin.pub
  Логинимся под пользователем git и устанавливаем gitolite:
  
  
  su git
  cd ~
  git clone git://github.com/sitaramc/gitolite
  gitolite/src/gl-system-install
  gl-setup -q ~/gitadmin.pub 

Особенность настройки gitolite заключается в том, что почти никакие операции по его настройке НЕ производятся напрямую на сервере. Чтобы добавить нового пользователя, репозиторий или изменить права доступа надо сделать git clone специального gitolite-admin репозитория, внести изменения и сделать git push. Дело в том, что gitolite использует целую систему хуков, чтобы эти изменения вступили в силу.
Итак, чтобы создать новый репозиторий и добавить нужных пользователей потребуется:

• Из-под пользователя, публичный ключ которого был добавлен в gitolite при его установке (или любого другого пользователя, обладающего достаточными правами на репозиторий gitolite-admin) исполняем:
  

  git clone git@server:gitolite-admin 

  
  Это, соответственно, создаст в текущей папке копию админ-репозитория. Он представляет собой две папки: conf и keydir. В папке conf хранится файл gitolite.conf, содержащий список репозиториев и прав доступа к ним. В папке keydir — публичные ключи пользователей, про которых должен знать gitolite.
• Чтобы добавить нового пользователя просто записываем его публичный ключ в папку keydir. Имя ключа до окончания .pub будет являться именем пользователя в системе gitolite. Примеры: user1.pub или john-smith.pub. В имени допустимы символы точки и подчеркивания. Чтобы добавить репозиторий и изменить права редактируем файл conf/gitolite.conf. Исходно он выглядит так:
  
  repo    gitolite-admin
          RW+     =   gitadmin
  repo    testing
          RW+     =   @all
  
  Добавим строчки:
  
  repo megaproject 
  RW+ = gitadmin user1 john-smith
Эти строчки описывают новый репозиторий megaproject, права на который имеют пользователи gitadmin, user1, john-smith.
• После чего применяем и отправляем все изменения:
  git add .
  git commit -a -m "New repo and users added"
  git push

Несколько слов о формате конфиг-файла:

• Существует возможность использовать группы. Причем как для пользователей, так и для репозиториев. Пример:
  

  @oss_repos = gitolite linux git perl rakudo entrans vkc 

  @staff = sitaram some_dev another-dev 

  
  @all — особая, предопределенная группа. Она описывает — в зависимости от контекста — всех аутентифицированных пользователей, или все репозитории.
• Базовые права доступа описываются следующим образом:
  
  • R — позволяет чтение
  • RW — позволяет делать push в существующий ref или создавать новый ref
  • RW+ — позволяет делать «push -f» или удалять ref (т.е. уничтожать информацию)
  • -(минус) — запрещает доступ

Работаем с вновь созданным репозиторием

Собственно, работа с gitolite с точки зрения пользователя совершенно традиционна. Следуя нашему примеру, разработчик может исполнить команды:
ssh — аутентификация через публичный ключ

Как вы, возможно, знаете, в ssh помимо традиционной аутентификации по паролю существует возможность пройти оную с использованием пары ключей. Аутентификация через публичный ключ — это когда вы генерируете пару ключей и отдаете публичный ключ на тот хост, который должен вас узнавать. После этого через ssh можно входить на удаленную машину не вводя пароль.
Чтобы сгенерировать пару ключей для своего пользователя исполните
ssh-keygen -t rsa
Эта команда создаст в папке ~/.ssh два файла: id_rsa и id_rsa.pub. Первый — это частный ключ, который следует хранить как зеницу ока, а второй (с расширением .pub) — это публичный ключ, который и нужно передавать на удаленный хост. На самом деле внутри этого файла просто одна длинная текстовая строка, которую можно передать просто как текст.
А на машине, доступ к которой требуется предоставить, необходимо внести указанный ключ в файлик ~/.ssh/authorized_keys того пользователя, доступ под которым необходимо организовать.

gitolite — принцип работы

Это для тех, кому интересно, как оно вообще устроено. Собственно, как уже понятно из описания, gitolite работает поверх ssh с использованием аутентификации через public-key (точнее, это наиболее популярная конфигурация).

На сервере заводится единственный реальный пользователь, через которого будет происходить работа с репозиториями. А «магия» gitolite заключается в том, что в authorized_keys эти ключики попадают с опцией «command=[path]/gl-auth-command ...». Эта опция предписывает ssh-серверу запускать указанную команду независимо от того, что реально хотел исполнить юзер. При этом оригинальная команда сохраняется в переменной SSH_ORIGINAL_COMMAND, которую и считывает gitolite, чтобы узнать, что от него хотели.