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

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

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

Источник

5 ответов

Решение

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

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

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

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

Если 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-shell
  • Создать репо на сервере
  • начать git pull / push для git@yourserver.com

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

Источник

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

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

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

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

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

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

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

Источник

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

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

Источник

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

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

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

Источник
Другие вопросы по тегам