gitosis vs gitolite？ [关闭]答案

【问题标题】：gitosis vs gitolite? [closed]gitosis vs gitolite？ [关闭]
【发布时间】：2012-06-04 21:01:35
【问题描述】：

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

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

【问题讨论】：

【解决方案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 用户一起做事，setting up a git server 的文档很短 - 因为它真的很容易做到。

总结：

使用和不使用专用 git 用户之间的唯一区别在于，如果您将 git 用户设置为使用git-shell，它将不允许自己做任何其他事情。不过，就充当 git 服务器而言，它与免安装解决方案相同

【讨论】：

在安装了 GitLab+Gitolite 这个野兽之后，如果您不需要对项目等进行精细控制，这是可行的方法。
感谢您的回答！实际上，当我说我不想为每个用户创建用户帐户时，我也应该提到我不希望我的 git 用户通过 ssh 访问服务器 shell。使用您的解决方案，我认为他们可以通过“git”用户访问 shell，对吧？
@wsams: git push -u origin master 你可以在它之后使用git push。我更喜欢 gito*，因为在我看来，访问 repo 的任何人都不应该关心它在远程系统上的绝对路径。
@ThiefMaster 猜测您的意思，如果您将 repos 放入 /home/git/，则访问项目的 url 是 git@server:project.git。
@wsams 阅读这部分答案“将 git 用户的 shell 更改为 git-shell”。

【解决方案2】：

主要区别在于 gitosis 现在已过时，不再积极维护。

Gitolite 很多more feature complete，刚刚发布了它的third version。

它最有趣的功能是Virtual Reference (VREF for short)，它允许您声明任意数量的update hook，它允许您通过以下方式限制推送：

目录/文件名：
假设您不希望初级开发人员将更改推送到 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。
等等……

【讨论】：

我已经使用 Gitolite 3 年多了。从来没有任何问题。我的生产和登台服务器对需要的存储库具有只读访问权限。然后与其他开发团队共享项目很容易。如果您已经了解 unix 和 git，也很容易设置 :)
Gitolite 文档包括与替代品的比较：gitolite.com/gitolite/gitolite.html#alt

【解决方案3】：

只是一个旁注。您还可以根据需要使用 Gerrit：

首先，Gerrit 似乎用于代码审查，但实际上您也可以将其用于管理用户并为他们提供良好定义的权限。您可以绕过代码审查（通过访问控制）并将其仅用于管理项目和 ssh 密钥。 Gerrit 有一个非常强大的访问控制机制：

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

【讨论】：

【解决方案4】：

要获得更快、更脏的解决方案，只需使用 git daemon 并进行点对点。 Here's an article 关于这样做。

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

【讨论】：

【解决方案5】：

我已经搞砸了一段时间，让一个 git 服务器使用 LDAP 访问、细粒度访问控制等......发现了一个启示：使用Gitlab：

如果您想要快速快速的安装方法：使用bitnami installer

【讨论】：

是的，但是 GitLab（使用 gitlab-shell）丢失了所有可以使用 Gitolite 轻松设置的 VREF 挂钩。很多人希望他们回来：github.com/gitlabhq/gitlab-shell/issues/14 和 github.com/gitlabhq/gitlab-shell/pull/85