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

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

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

Я ищу установку 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-сервера он идентичен решению без установки.

Основное отличие состоит в том, что 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Реализацию.

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

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

Обзор кода Gerrit

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

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

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

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

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

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

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

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