Гитоз против Гитолита? [закрыто]

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

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

Ответы на вопрос(5)

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

git repositories fine grained access (afaik gitlab uses gitolite under the hood)

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

 12 февр. 2014 г., 17:41
Да, но GitLab (с gitlab-shell) потерял все хуки VREF, которые вы могли легко установить с помощью Gitolite. И многие люди хотели бы их вернутьgithub.com/gitlabhq/gitlab-shell/issues/14 а такжеgithub.com/gitlabhq/gitlab-shell/pull/85

мерзавец демон и идти в одноранговом режиме.Вот статья о том, чтобы сделать это.

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

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

Гитолит многоболее полная функцияи только что выпустил еготретья версия.

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

dir/file name:
Say you don't want junior developers pushing changes to the Makefile, because it's quite complex:
- VREF/NAME/Makefile = @junior-devs

number of new files:
Say you don't want junior developers pushing more than 9 files per commit, because you want them to make small commits:
- VREF/COUNT/9/NEWFILES = @junior-devs

advanced filetype detection:
Sometimes a file has a standard extension (that cannot be 'gitignore'd), but it is actually automatically generated. Here's one way to catch it:
- VREF/FILETYPE/AUTOGENERATED = @all
See src/VREF/FILETETYPE to see the detection mechanism.

checking author email:
Some people want to ensure that "you can only push your own commits".
- VREF/EMAIL-CHECK = @all
See src/VREF/EMAIL-CHECK.

voting on commits:
A basic implementation of voting on a commit is surprisingly easy:
- 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
See src/VREF/VOTES for the implementation.

and so on...

 30 мая 2013 г., 01:54
Я использую Gitolite уже более 3 лет. Никогда не было проблем с этим. Наши производственные и промежуточные серверы имеют доступ только для чтения к репозиториям. И тогда легко поделиться проектом с другими командами разработчиков. Кроме того, его легко установить, если вы уже знаете Unix и Git :)
 20 июн. 2014 г., 03:52
Спасибо, что действительно ответили на вопрос!
 05 дек. 2012 г., 08:25
Gitolite действительно хорошо сделан и очень прост в использовании и настройке.
 12 апр. 2015 г., 04:26
Gitolite документация включает в себя сравнения с альтернативами:gitolite.com/gitolite/gitolite.html#alt

Gerrit для ваших нужд:

Gerrit Code Review

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

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

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

Решение Вопроса

m.

You can just use git.

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

The no-install solution

Если 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
Setting up a git server is easy.

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

В итоге:

Install git Create a user named git Add your and your team's public keys to the git user's .ssh/authorized_keys file Change the git user's shell to be git-shell Create repos on the server start git pull/pushing to [email protected]

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

 18 мая 2013 г., 13:25
@wsams прочитайте эту часть ответа "Измените оболочку пользователя git на git-shell".
 07 сент. 2012 г., 12:50
@wsams:git push -u origin master и вы можете использоватьgit push после этого. Я предпочитаю gito *, потому что, по моему мнению, никто, обращающийся к репо, не должен заботиться об абсолютном пути к удаленной системе.
 04 июн. 2012 г., 23:21
После установки зверя, который называется GitLab + Gitolite, если вам не требуется точный контроль над проектами и т. Д., То это путь.
 greydet05 июн. 2012 г., 19:44
Спасибо за этот ответ! На самом деле, когда я сказал, что не хочу создавать учетные записи пользователей для каждого, я должен был также упомянуть, что не хочу, чтобы мои пользователи git имели доступ к оболочке сервера через ssh. С вашим решением, я думаю, они получат доступ к оболочке через "git". пользователь, верно?
 07 сент. 2012 г., 13:44
@ThiefMaster делает дикие предположения о том, что вы имеете в виду, если вы положили репо в/home/git/ URL для доступа к проекту[email protected]:project.git.

Ваш ответ на вопрос