gitosis vs gitolite？ [已关闭]

Question

我正在寻找安装 git 服务器来与我的团队共享项目。我不想在服务器上为每个需要 git 访问权限的开发人员创建一个具有 SSH 访问权限的用户帐户。似乎有两个并发解决方案可以解决这个问题：gitosis 和 gitolite。

我找不到这两种解决方案之间的任何比较。它们之间的主要区别是什么？还有其他类似的解决方案吗？

Answer 1

我正在寻找安装 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 用户设置为使用 git-shell

，它将不允许自己执行任何其他操作。不过，就充当 git 服务器而言，它与免安装解决方案相同

Answer 2

主要区别是 gitosis 现已过时，并且不再积极维护。

Gitolite

功能更齐全，刚刚发布了第三个版本。

它最有趣的功能是

虚拟参考（简称VREF），它允许您声明任意数量的update hook，这允许您通过以下方式限制推送：

目录/文件名: 假设您不希望初级开发人员将更改推送到 Makefile，因为它非常复杂：

- VREF/NAME/Makefile = @junior-devs
新文件数量: 假设您不希望初级开发人员每次提交推送超过 9 个文件，因为您希望他们进行
小提交：
- VREF/COUNT/9/NEWFILES = @junior-devs
高级文件类型检测：有时一个文件有一个标准扩展名（不能被“gitignore”），但它实际上是自动生成的。这是捕获它的一种方法：

- 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
。
等等...

Answer 3

只是一个旁注。您还可以使用

Gerrit 来满足您的需求：

Gerrit 代码审查

首先，Gerrit 似乎用于代码审查，但实际上您也可以使用它来管理用户并为他们提供良好的定义权限。您可以

绕过代码审查（通过访问控制）并仅将其用于管理项目和 ssh 密钥。 Gerrit 拥有非常强大的访问控制机制：

Gerrit 访问控制

您可以限制推送任何分支、标签或您可以想象的访问控制文档中定义的任何内容。

Answer 4

要获得更快、更脏的解决方案，只需使用

git daemon 并进行点对点。这是一篇关于这样做的文章。

编辑：我认识到这并不能严格回答OP的问题。我把这个放在这里主要是为了那些像我一样在寻找一种低级和肮脏的方式来共享代码直到建立企业 github 帐户时遇到这个问题的人。

Answer 5

我已经闲逛了一段时间，想让 git 服务器与 LDAP 访问、细粒度访问控制等一起工作......发现了一个启示：使用

Gitlab：

如果您想要快捷的安装方法：使用

bitnami安装程序