Гитоз против гитолита?

Ответ 1

Я ищу установку сервера git для совместного использования проектов с моей командой.

Вы можете просто использовать git.

Чтобы иметь сервер git, единственное, что вам нужно на удаленном сервере, - git. Если вам не нужны мелкие разрешения (совместное использование только вашей командой предполагает возможность) или любые дополнительные функции, вам не нужен гитолит или что-то подобное.

Решение без установки

Если на удаленном сервере доступно git, вы можете делать то, что вы просите прямо сейчас, ничего не делая

ssh [[email protected]]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare

Локально:

cd projects/are/here/project
git remote add origin [[email protected]]server:repos/are/here/project.git
git push -u origin master

Настройка сервера git проста.

Если вы хотите сделать что-то со специальным пользователем git, docs для настройки сервера git являются короткими - потому что это действительно легко сделать.

Вкратце:

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

Единственное различие между использованием выделенного пользователя git и нет, заключается в том, что если вы настроите пользователя git на использование git-shell, он не позволит себе ничего делать. С точки зрения действия как сервера git, хотя он идентичен решению без установки

Ответ 2

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

Gitolite намного больше больше полной версии и только что выпустил свою третью версию.

Его наиболее интересной особенностью является Virtual Reference (короткое VREF), что позволяет объявлять как можно больше привязка обновления, которая позволяет вам ограничить нажатие на:

• имя файла/файла:
  Скажем, вы не хотите, чтобы младшие разработчики вносили изменения в 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

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

Обзор кода Gerrit

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

Управление доступом Gerrit

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

Ответ 4

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

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

Ответ 5

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

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

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