гитоз или гитолит? [закрыто]


139

Я ищу установку git-сервера, чтобы делиться проектами с моей командой. Я не хочу создавать учетную запись пользователя на сервере с доступом SSH для каждого разработчика, которому нужен доступ git. Кажется, есть два параллельных решения, которые решают эту проблему: гитозис и гитолит.

Я не смог найти никакого сравнения между обоими решениями. Каковы основные различия между ними? Есть ли другое подобное решение?

Ответы:


191

Я ищу установку git-сервера, чтобы делиться проектами с моей командой.

Вы можете просто использовать 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, документация по настройке сервера git будет короткой, потому что это действительно довольно просто сделать.

В итоге:

  • Установить git
  • Создайте пользователя с именем git
  • Добавьте свои открытые ключи и открытые ключи вашей команды в .ssh/authorized_keysфайл пользователя git
  • Измените оболочку пользователя git на git-shell
  • Создавайте репозитории на сервере
  • начать git pull / pushing на git@yourserver.com

Только разница между использованием выделенного пользователя GIT и нет, в том , что если вы настроите пользователь мерзавец использовать git-shellне будет позволять себе делать что - нибудь еще. Однако с точки зрения работы в качестве git-сервера он идентичен решению без установки.


13
После установки зверя, которым является GitLab + Gitolite, если вам не нужен точный контроль над проектами и т. Д., Это способ.
Эндрю Т. Финнелл

Спасибо за такой ответ! На самом деле, когда я сказал, что не хочу создавать учетные записи пользователей для каждого из них, я должен был также упомянуть, что не хочу, чтобы мои пользователи git имели доступ к оболочке сервера через ssh. Думаю, с вашим решением они будут иметь доступ к оболочке через пользователя "git", верно?
greydet 05

2
@wsams: git push -u origin masterи вы можете использовать git pushпосле него. Я предпочитаю gito *, потому что, по моему мнению, никто, обращающийся к репо, не должен заботиться об абсолютном пути, который он имеет в удаленной системе.
ThiefMaster

8
@ThiefMaster делает дикие предположения о том, что вы имеете в виду, если вы помещаете репозитории в /home/git/URL-адрес для доступа к проекту git@server:project.git.
AD7six

1
@wsams прочитал эту часть ответа «Измените оболочку пользователя git на git-shell».
fabspro

143

Основное отличие состоит в том, что gitosis устарел и больше не поддерживается активно.

Gitolite гораздо более полнофункциональный и только что выпустил свою третью версию .

Его наиболее интересной функцией является виртуальная ссылка (сокращенно VREF), которая позволяет вам объявлять столько ловушек обновления, сколько вы хотите, что позволяет вам ограничивать отправку:

  • dir / file name :
    скажем, вы не хотите, чтобы младшие разработчики вносили изменения в Makefile, потому что это довольно сложно:
    - VREF/NAME/Makefile = @junior-devs

  • количество новых файлов :
    скажем, вы не хотите, чтобы младшие разработчики помещали более 9 файлов за одну фиксацию, потому что вы хотите, чтобы они совершали небольшие коммиты:
    - VREF/COUNT/9/NEWFILES = @junior-devs

  • расширенное определение
    типа файла : иногда файл имеет стандартное расширение (которое не может быть 'gitignore'd), но на самом деле оно создается автоматически. Вот один из способов , чтобы поймать его:
    - 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Реализацию.

  • и так далее...


3
Пользуюсь Гитолитом уже более 3-х лет. Никаких проблем с этим не было. I наши производственные и промежуточные серверы имеют доступ только для чтения к необходимым репозиториям. А потом поделиться проектом с другими командами разработчиков - это несложная задача. Также это легко настроить, если вы уже знаете unix и git :)
комплимент

Документация Gitolite включает сравнения с альтернативами: gitolite.com/gitolite/gitolite.html#alt
Quinn Comendant

15

Просто примечание на полях. Вы также можете использовать Gerrit для своих нужд:

Обзор кода Gerrit

Сначала кажется, что Gerrit используется для проверки кода, но на самом деле вы можете использовать его также для управления пользователями и предоставления им хорошо определенных разрешений. Вы можете обойти проверку кода (через контроль доступа ) и использовать его только для управления проектами и ssh-ключами. У Геррита действительно мощный механизм контроля доступа:

Контроль доступа Gerrit

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


8

Чтобы получить еще более быстрое и грязное решение, просто используйте git daemon и перейдите в одноранговую сеть. Вот статья об этом.

Изменить: я понимаю, что это не совсем ответ на вопрос OP. Я поместил это здесь в основном для тех, кто, как я, сталкивался с этим, ища грязный и грязный способ поделиться кодом, пока не будет настроена корпоративная учетная запись github.


2

Я какое-то время возился, чтобы заставить git-сервер работать с доступом LDAP, мелкозернистым контролем доступа и т.д ... Нашел откровение: используйте Gitlab :

  • репозитории git
  • мелкозернистый доступ (afaik gitlab использует под капотом гитолит)

если вам нужен быстрый и быстрый метод установки: воспользуйтесь установщиком bitnami


Да, но GitLab (с gitlab-shell) потерял все хуки VREF, которые вы могли легко настроить с помощью Gitolite. И многие люди хотели бы их вернуть: github.com/gitlabhq/gitlab-shell/issues/14 и github.com/gitlabhq/gitlab-shell/pull/85
VonC
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.