Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
В чем преимущества по сравнению с 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 не сохраняет исходных прав на файлы.
Поэтому мы для себя сделали хитрый скрипт, который разбирает загружаемые файлики и интеллектуально выставляет права, максимально похожие на правильные.
Если кому-то интересно — могу опубликовать как топик.
Не исключено, что кто-то знает совсем красивое решение. Коли так — буду рад прочитать :)
Причем, разумеется, нам хотелось, чтобы каждый push в центральный репозиторий обновлял webroot разрабатываемого сайта.
И все было бы хорошо, но git не сохраняет исходных прав на файлы.
Поэтому мы для себя сделали хитрый скрипт, который разбирает загружаемые файлики и интеллектуально выставляет права, максимально похожие на правильные.
Если кому-то интересно — могу опубликовать как топик.
Не исключено, что кто-то знает совсем красивое решение. Коли так — буду рад прочитать :)
git отлично сохраняет права на файлы, проблема видимо была в чём-то ещё, опишите
Не сохраняет.
Даже в официальной доке написано, что git обращает внимание только на executable bit:
Note that the files all have mode 644 or 755: git actually only pays attention to the executable bit.
Попробуйте сделать с исходной папки git push, а потом в новую git clone — права внутри папок будут разные.
Даже в официальной доке написано, что git обращает внимание только на executable bit:
Note that the files all have mode 644 or 755: git actually only pays attention to the executable bit.
Попробуйте сделать с исходной папки git push, а потом в новую git clone — права внутри папок будут разные.
Совсем красивое решение — это любой deployment инструмент (Capistrano?). В задачи VCS входит отслеживание изменений в исходном коде. Весь процесс развертывания сайтов гораздо лучше описывается в интрументах, предназначенных для этого.
У gitolite плохо что нужен центральный суперадмин чтобы управлять доступом ко всем репозиториям. Не подходит для тех случаев когда нужно чтобы отдельные пользователи могли управлять правами доступа на те репозитории, которыми они владеют.
Промахнулся, этот комментарий вам.
В документации говорят что можно передать права управления группой репозиториев кокретному пользователю.
Посту не хватает буквально пары полезных команд:
(предположим ваш паблик-кей уже добавлен владельцем репы в папку с ключами и вам прописаны права в gitolite.conf)
Добавить удалённый репозиторий:
После данной операции команда
выдаст примерно
и у вас появляется возможность затягивать и пушить ветки минуя origin таким образом:
В общем и целом gitolite весьма удобен если разработчикам необходим обмен ветками до пуша на корпоративный ориджин или гитхаб.
Зачем это нужно? Например над проектом работает несколько групп по несколько человек, в таком случае для минимума конфликтов мерджит изменения тимлидер, затем сливает изменения с ориджином и возможно деплоит на стэйдж.
gitolite можно поднять на том-же vds сервере где хостится стейдж например, что позволит гибко распределять права доступа и сведёт к минимуму краши стэйджа в рамках одного root'а.
(предположим ваш паблик-кей уже добавлен владельцем репы в папку с ключами и вам прописаны права в 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. Спасибо.
Если знаете — напишите как админа восстановить, если случайно удалили ему доступ. Мучаюсь уже час…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с gitolite