Система Gitolite позволяет значительно увеличить возможности git репозиториев по разграничению прав доступа. Она представляет из себя дополнительную прослойку поверх git'a и работает по ssh или http. С помощью данной системы можно устанавливать права на скачивание/запись/перезапись не только самих репозиториев, но и веток в них и даже тегов. Так же благодаря механизму hooks (хуков), gitolite позволяте пользователю расширить возможности по управлению репозиторием. Например, организовать систему Push to Deploy.
Настройка данной системы не совсем тривиальна и в данном материале мы постараемся рассмотреть все сложности которые могут возникнуть.
Установка Gitolite
Устанавливаем из портов, при этом подтвердим создание нового пользователя в системе под которым и будет работать gitolite. Будет создан пользователь git с домашней дерикторией /usr/local/git
cd /usr/ports/devel/gitolite
make install clean
Поменять рабочие дериктории любого пользователя (если вам не нравится дериктория по умолчнию) можно командой
pw usermod git -d /home/git
Для доступа к репозиториям по ключу создаем его. Или можем воспользоваться уже существующем.
Для создания ключа заходим в git-bash (для виндовс) и вводим команду на генерацию ключа. Для Unix систем просто испольняем эту команду в консоли.
ssh-keygen -t rsa
Следуя инструкциям приложения получим 2 ключа. Закрытый (без расширения или с .ppk) необходимо сохранить в домашнюю дерикторию текущего пользователя в папку .ssh. Например, у меня эта папка - "C:\Users\HOME\.ssh\". Думаю говорить, что данный файл не должен попасть в чужие руки излишне. По умолчанию, ключ генерируется с именем "id_rsa", но если мы хотим использовать на локальном компьютере несколько ключей для разных целей, то его стоит переименовать.
Публичный ключ (с расширеним pub ) небходимо скопировать на сервер в домашнюю дерикторию созданного пользователя. Далее необходимо задать имя пользователя которое будет использовать система gitolite под этим ключем. Для этого просто переименуем этот ключ в формате <username>.pub, где <username> - имя пользователя внутри системы gitolite. Потом на это имя будут прикрепляться права доступа. Установим этот первый ключ в системе gitolite'a
gitolite setup -pk /home/git/<username>.pub
после чего этот ключ будет зарегистрирован и его можно проверить в файле /home/git/.ssh/authorized_keys
Эти настройки нужны только для первой инициализации, все действия с другими пользователями будут настраиваться с помощью созаданного репозитория gitolite-admin.
Теперь, если мы переименовали приватный ключ на нашей локальной машине, то необходимо сделать настройки, чтобы для сервера с нашим gitolite'ом использовался именно он, так как система по умолчанию ищет ключ с именем "id_rsa". В таком случае добавим в свой локальный ".ssh/config":
Host <ip адрес сервера>
User git
Hostname <адрес сервера>
Port 2222
IdentityFile ~/.ssh/<наш приватный ключ>
После этого из консоли все отлично работает, но из моего редактора (PhpStorm), не читает прописанные таким образом ключи. Возможно как то можно настроить в на стройках редактора, но я просто меня используемый редактором git бинарник на поставляемый с git bash. В настройках вкладка Version control раздел Git и в поле Path to Git executable ставим - C:\Program Files\Git\bin\git.exe (путь до бинарника из поставки GitBash). Параметр SSH executable меняем на Native. После этого настройки из файла ".ssh/config" подхватываются редактором и репозиторием можно управлять прямо из него.
Настройка прав на проектах
Все настройки в системе хранятся немного не обычным способом. Что бы их подправить необходимо скачать(git clone) уже существующую репозиторию gitolite-admin с конфигурацией сервера, подредактировать её и "закомитить обратно" (git push).
Попробуем выкачать репозиторий с настройками(для пользователей Windows это удобно делать в консоли gitBash устанавливаемой вместе с git) и произвести некоторые настройки. Для этого из под пользователя ключ которого мы добавили выше выполним команду
git clone ssh://git@123.123.123.123:22/gitolite-admin
где git@ - имя пользователя созданное при установке gitolite
123.123.123.123:22 - адрес и порт сервера
В скаченном репозитории мы увидим две папки - conf и keydir
Для добавления новых пользователей под управление gitolite необходимо поместить публичный ключ этого пользователя в папку keydir и переименовать в его имя пользователя которое потом будет использоваться в конфигурационном файле для раздачи прав. Например для пользователя sergey, файл должен называться sergey.pub. После этого подредактируем конфигурационный файл в папке conf.
Так как я первый ключ создавал с именем admin.pub, то мой файл пока выглядит так
repo gitolite-admin
RW+ = admin
repo testing
RW+ = @all
Добавим в него новый проект и нового пользователя sergey
repo newproject
RW+ = admin sergey
Макрос "@all", отвечает за всех пользователей ключи которых есть в "keydir".
Так же для мы можем разбивать пользователей и на группы
@admins = <user1> <user2>
@developers = @admins sergey
@teamlead = <user3>
repo gitolite-admin
RW+ = @admins
repo project
R = @developers
W+ = @teamlead
Возможные права:
- R — позволяет чтение
- RW — позволяет делать push в существующий ref или создавать новый ref
- RW+ — позволяет делать «push -f»(с перезаписью существующих) или удалять ref (т.е. уничтожать информацию)
- -(минус) — запрещает доступ
Так же можно раздавать права и на отдельные файлы, ветки и теги. Для примера сделаем чтобы @teamlead имели доступ ко всему, а @developers имели доступ только на чтение к ветке "production" и тегам "release*" (но не могли создавать такие теги).
repo project
RW+ NAME/ = @teamlead
RW+ = @teamlead
R production = @developers
- refs/heads/production = @developers
R refs/tags/release.* = @developers
- refs/tags/release.* = @developers
R NAME/project.conf = @developers
- NAME/project.conf = @developers
RW+ NAME/ = @developers
RW+ = @developers
Правила проверяются последовательно, так что порядок их следования важен.
Теперь сохраним наши изменения конфигурационного файла и "закоммитим" его на сервер.
git add conf/gitolite.conf
git commit -m "add new repos - newproject"
git push origin master
Пустая папка под наш проект создастся автоматически
>> Initialized empty Git repository in /home/git/repositories/newproject.git/
Новый проект проинициализирован, теперь можно скачать его с локальной машины.
Изменения из локального(уже существующего) репозитория в удаленном сохраняем командой
git push origin master
#или
git push origin beta:production #из локальной ветаки beta в удаленную ветку production
Посмотреть содержание всех веток в репозитории можно командой
git fetch origin
Исполнив её мы не поменяем файлы в нашей рабочей копии. А чтобы скачать изменения с одной из веток, допустим master, то можно исполнить команду
git pull origin master
Последняя версия ветки master с репозитория скачается в вашу рабочую копию проекта.
Если мы не делали git clone, то подключить уже существующий репозиторий к удаленному можно командой
git remote add origin ssh://git@123.123.123.123:22/newproject
Буду признателен за комментарии дополняющие материал. А если статья была Вам полезна, то за клик по рекламе.
Система Gitolite позволяет значительно увеличить возможности git репозиториев по разграничению прав доступа. Она представляет из себя дополнительную прослойку поверх git'a и работает по ssh или http. С помощью данной системы можно устанавливать права на скачивание/запись/перезапись не только самих репозиториев, но и веток в них и даже тегов. Так же благодаря механизму hooks (хуков), gitolite позволяте пользователю расширить возможности по управлению репозиторием. Например, организовать систему Push to Deploy.
Настройка данной системы не совсем тривиальна и в данном материале мы постараемся рассмотреть все сложности которые могут возникнуть.