Я ищу установку сервера git для обмена проектами с моей командой. Я не хочу создавать учетную запись пользователя на сервере с SSH-доступом для каждого разработчика, которому нужен доступ 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, docs для настройки сервера git являются короткими - потому что это действительно легко сделать.
Вкратце:
.ssh/authorized_keys git
git-shellЕдинственное различие между использованием выделенного пользователя git и нет, заключается в том, что если вы настроите пользователя git на использование git-shell, он не позволит себе ничего делать. С точки зрения действия как сервера git, хотя он идентичен решению без установки
Основное различие заключается в том, что гитоз теперь устарел и больше не поддерживается.
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 для реализации.
и т.д.
Просто сидение. Вы также можете использовать Gerrit для ваших нужд:
Сначала кажется, что Gerrit используется для проверки кода, но вы можете использовать его также для управления пользователями и предоставления им правильных разрешений. Вы можете обходить код-обзор (через контроль доступа) и использовать его только для управления проектами и ssh-ключами. У Gerrit действительно сильный механизм контроля доступа:
Вы можете ограничить нажатие на любые ветки, теги или все, что вы можете себе представить, которые определены в документе управления доступом.
Для еще более быстрого и более грязного решения просто используйте git daemon и переходите к одноранговой сети. Вот статья об этом.
Изменить: я признаю, что это строго не отвечает на вопрос OP. Я помещал это здесь в основном для тех, кто, как и я, которые сталкиваются с этим, ища доступный и грязный способ совместного использования кода до создания учетной записи предприятия github.
Я некоторое время занимался беспорядком, чтобы получить сервер git, работающий с доступом к LDAP, мелкозернистый контроль доступа и т.д. Найденное откровение: используйте Gitlab:
если вам нужен быстрый и быстрый способ установки: используйте установщик bitnami