Знакомство с gitolite

В чем преимущества по сравнению с gitosis? Просто я использую последний и не вижу у gitolite каких-либо преимуществ.

Жаль, что в статье не описано главное преимущество gitolite — возможность раздавать права доступа к веткам, тегам и т.д.

Ну примерно так:

@owners = vova dima

@admins = @owners vasya petya

@gitusers = @owners glash klasha mdprokhorov

# gitolite-admin

repo gitolite-admin
RW+ = @admins

repo russia/moscow
RW+ sortir/ = adudaev
RW+ = @owners seriozha

repo russia/piter
RW+ = @owners @admins



Вроде все понятно в конфиге при этом :)
Конфиг писал конечно же из головы и по памяти, лучше почитайте документацию, а не настраивайте, как я ;)

… а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.

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

Кстати, gitolite мы для себя поднимали для того, чтобы вести совместную разработку веб-сайта.
Причем, разумеется, нам хотелось, чтобы каждый push в центральный репозиторий обновлял webroot разрабатываемого сайта.
И все было бы хорошо, но git не сохраняет исходных прав на файлы.

Поэтому мы для себя сделали хитрый скрипт, который разбирает загружаемые файлики и интеллектуально выставляет права, максимально похожие на правильные.
Если кому-то интересно — могу опубликовать как топик.

Не исключено, что кто-то знает совсем красивое решение. Коли так — буду рад прочитать :)

У gitolite плохо что нужен центральный суперадмин чтобы управлять доступом ко всем репозиториям. Не подходит для тех случаев когда нужно чтобы отдельные пользователи могли управлять правами доступа на те репозитории, которыми они владеют.

В документации говорят что можно передать права управления группой репозиториев кокретному пользователю.

Посту не хватает буквально пары полезных команд:
(предположим ваш паблик-кей уже добавлен владельцем репы в папку с ключами и вам прописаны права в gitolite.conf)

Добавить удалённый репозиторий:

git remote add repoholdername git@server.com:project.git

После данной операции команда

~> git remote show

выдаст примерно

origin*
repoholdername

и у вас появляется возможность затягивать и пушить ветки минуя origin таким образом:

~> git fetch repoholder branchname
~> git push repoholder branchname

В общем и целом gitolite весьма удобен если разработчикам необходим обмен ветками до пуша на корпоративный ориджин или гитхаб.
Зачем это нужно? Например над проектом работает несколько групп по несколько человек, в таком случае для минимума конфликтов мерджит изменения тимлидер, затем сливает изменения с ориджином и возможно деплоит на стэйдж.
gitolite можно поднять на том-же vds сервере где хостится стейдж например, что позволит гибко распределять права доступа и сведёт к минимуму краши стэйджа в рамках одного root'а.

Хороший пост, чтобы быстро разобраться в gitolite. Спасибо.

Если знаете — напишите как админа восстановить, если случайно удалили ему доступ. Мучаюсь уже час…