Я ищу установку сервера git, чтобы делиться проектами со своей командой. Я не хочу создавать учетную запись пользователя на сервере с доступом по SSH для каждого разработчика, которому нужен доступ к git. Кажется, есть два параллельных решения, которые охватывают эту проблему: gitosis и gitolite.
Я не мог найти никакого сравнения между обоими решениями. Каковы основные различия между ними? Есть ли другое подобное решение?
Я ищу установку сервера git, чтобы делиться проектами со своей командой.
Чтобы иметь сервер git, единственное, что вам нужно на удаленном сервере, это git. Если вам не требуются детальные разрешения (совместное использование только с вашей командой предполагает, что это возможно) или какие-либо дополнительные функции, вам не нужен gitolite или что-то подобное.
Если git доступен на удаленном сервере, вы можете делать то, о чем просите, прямо сейчас, ничего не делая.
ssh [user@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare
Локально:
cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git push -u origin master
Если вы хотите делать что-то с выделенным пользователем git, документация для настройка git-сервера короткая, потому что это действительно очень легко сделать.
В итоге:
.ssh/authorized_keys пользователя git.git-shellЕдинственная разница между использованием выделенного пользователя git и нет, заключается в том, что если вы настроите пользователя git на использование git-shell, он не позволит себе делать что-либо еще. Однако с точки зрения работы в качестве сервера git он идентичен решению без установки.
git push origin master вместо git push.
- person wsams; 06.09.2012
git push -u origin master и после него можно использовать git push. Я предпочитаю gito*, потому что, на мой взгляд, никто, обращающийся к репозиторию, не должен заботиться об абсолютном пути к нему в удаленной системе.
- person ThiefMaster; 07.09.2012
/home/git/, URL-адрес для доступа к проекту будет git@server:project.git.
- person AD7six; 07.09.2012
git-shell @fabspro.
- person wsams; 20.05.2013
Основное отличие состоит в том, что gitosis устарел и больше не поддерживается активно.
Gitolite обладает гораздо большей функциональностью и только что выпустил третья версия.
Его самая интересная функция — виртуальная ссылка (сокращенно VREF) который позволяет вам объявить столько хуков обновлений, сколько вы хотите, что позволяет вам ограничить от:
имя каталога/файла:
Скажем, вы не хотите, чтобы младшие разработчики вносили изменения в Makefile, потому что он довольно сложный:- VREF/NAME/Makefile = @junior-devs
количество новых файлов:
Допустим, вы не хотите, чтобы младшие разработчики загружали более 9 файлов за один коммит, потому что вы хотите, чтобы они делали небольшие коммиты:
- VREF/COUNT/9/NEWFILES = @junior-devs
Расширенное определение типа файла:
Иногда файл имеет стандартное расширение (которое нельзя «проигнорировать git»), но на самом деле оно создается автоматически. Вот один из способов поймать его:- VREF/FILETYPE/AUTOGENERATED = @all
См. src/VREF/FILETETYPE, чтобы увидеть механизм обнаружения.
проверка электронной почты автора:
Некоторые люди хотят убедиться, что «вы можете отправлять только свои собственные коммиты».- VREF/EMAIL-CHECK = @all
См. src/VREF/EMAIL-CHECK.
голосование за фиксацию:
Базовая реализация голосования за фиксацию на удивление проста:- VREF/EMAIL-CHECK = @all.# 2 votes required to push master, but trusted devs don't have this restriction# RW+ VREF/VOTES/2/master = @trusted-devs# - VREF/VOTES/2/master = @devs
См. src/VREF/VOTES для реализации.
и так далее...
Просто примечание. Вы также можете использовать Gerrit для своих нужд:
Сначала кажется, что Gerrit используется для проверки кода, но на самом деле вы можете использовать его также для управления пользователями и предоставления им четко определенных разрешений. Вы можете обойти code-review (через управление доступом) и использовать его только для управления проектами и ssh-ключами. У Геррита действительно сильный механизм контроля доступа:
Вы можете ограничить отправку любых ветвей, тегов или всего, что вы можете себе представить, что определено в документе управления доступом.
Для еще более быстрого и грязного решения просто используйте git daemon и перейдите пиринговый. Вот статья об этом.
Изменить: я понимаю, что это не совсем отвечает на вопрос ОП. Я размещаю это здесь в основном для тех, кто, как и я, сталкивается с этим, ища простой и грязный способ поделиться кодом, пока не будет настроена корпоративная учетная запись github.
Я какое-то время возился, чтобы заставить сервер git работать с доступом LDAP, мелкозернистым контролем доступа и т. Д. Нашел откровение: используйте Гитлаб:
если вам нужен быстрый и быстрый метод установки: используйте установщик bitnami
