git gitosis 与 gitolite？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10888300/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
gitosis vs gitolite?
提问by greydet
I am looking for installing a git server to share projects with my team. I don't want to create a user account on the server with SSH access for each developer that needs a git access. It seems there is two concurrent solutions that cover this issue : gitosis & gitolite.
我正在寻找安装 git 服务器以与我的团队共享项目。我不想在服务器上为每个需要 git 访问权限的开发人员创建一个具有 SSH 访问权限的用户帐户。似乎有两个并发解决方案涵盖了这个问题：gitosis 和 gitolite。
I could not find any comparison between both solutions. What are the main differences between them? Are there other similar solution?
我找不到两种解决方案之间的任何比较。它们之间的主要区别是什么？还有其他类似的解决方案吗？
回答by AD7six
I am looking for installing a git server to share projects with my team.
我正在寻找安装 git 服务器以与我的团队共享项目。
You can justuse git.
你可以只使用git。
To have a git server the only thing you need on the remote server is git. If you don't require fine-grained permissions (sharing with only your team suggests that's a possibility) or any extra features, you don't need gitolite, or similar.
要拥有一个 git 服务器，您在远程服务器上唯一需要的就是 git。如果您不需要细粒度权限（仅与您的团队共享表明这是一种可能性）或任何额外功能，则不需要 gitolite 或类似的。
The no-install solution
免安装解决方案
If git is available on the remote server, you can do what you're asking right now, without doing anything
如果 git 在远程服务器上可用，您可以立即执行您所要求的操作，而无需执行任何操作
ssh [user@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare
Locally:
本地：
cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git push -u origin master
Setting up a git server is easy.
设置 git 服务器很容易。
If you want to do things with a dedicated git user, the docs for setting up a git serverare short - because it really is quite easy to do.
如果你想和一个专门的 git 用户一起做事，设置 git 服务器的文档很短——因为它真的很容易做到。
In summary:
总之：
- Install git
- Create a user named git
- Add your and your team's public keys to the git user's
.ssh/authorized_keysfile - Change the git user's shell to be
git-shell - Create repos on the server
- start git pull/pushing to [email protected]
- 安装 git
- 创建一个名为 git 的用户
- 将您和您团队的公钥添加到 git 用户的
.ssh/authorized_keys文件中 - 将 git 用户的 shell 更改为
git-shell - 在服务器上创建 repos
- 开始 git pull/push 到 [email protected]
The onlydifference between using a dedicated git user and not, is that if you setup the git user to use git-shellit won't allow itself to do anything else. In terms of acting as a git server though, it's identical to the no-install solution
使用专用 git 用户与不使用的唯一区别是，如果您设置 git 用户使用git-shell它，则它不允许自己做任何其他事情。不过，就充当 git 服务器而言，它与免安装解决方案相同
回答by VonC
The main difference is that gitosis is now obsolete, and not actively maintained anymore.
主要区别在于 gitosis 现在已经过时，不再积极维护。
Gitolite is much more feature complete, and just released its third version.
Gitolite 的功能更加完整，并且刚刚发布了它的第三个版本。
Its most interesting feature is the Virtual Reference (VREF for short)which allows you to declare as many update hookas you want, which allows you to restrict a push by:
它最有趣的功能是虚拟引用（简称 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-devsnumber of new files:
Say you don't want junior developers pushing more than 9 files per commit, because you want them to make smallcommits:- VREF/COUNT/9/NEWFILES = @junior-devsadvanced 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
Seesrc/VREF/FILETETYPEto see the detection mechanism.checking author email:
Some people want to ensure that "you can only push your own commits".- VREF/EMAIL-CHECK = @all
Seesrc/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
Seesrc/VREF/VOTESfor the implementation.and so on...
dir/file name：
假设您不希望初级开发人员将更改推送到 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实现。等等...
回答by Fatih Arslan
Just a sidenote. You can also use Gerritfor your needs:
只是一个旁注。您还可以根据需要使用Gerrit：
First it seems that Gerrit is used for Code review, but you can actually use it also for managing users and give them good defined permissions. You can bypasscode-review(trough access controls) and use it just for managing projects and ssh-keys. Gerrit has a really strong access control mechanism:
首先，似乎 Gerrit 用于代码，但实际上您也可以将其用于管理用户并赋予他们良好定义的权限。您可以绕过代码（通过访问控制）并将其仅用于管理项目和 ssh 密钥。Gerrit 有一个非常强大的访问控制机制：
You can restrict to push for any branches, tags or anything you can imagine that is defined in the access controls document.
您可以限制推送访问控制文档中定义的任何分支、标签或您可以想象的任何内容。
回答by Tim Keating
For an even quicker and dirtier solution, just use git daemonand go peer-to-peer. Here's an articleabout doing just that.
对于更快更脏的解决方案，只需使用git daemon并进行点对点。这是一篇关于这样做的文章。
Edit: I recognize this doesn't strictly answer the OP's question. I put this here mainly for those, like me, who come across this while looking for a down and dirty way to share code until an enterprise github account gets set up.
编辑：我承认这并没有严格回答 OP 的问题。我把它放在这里主要是为了那些像我这样的人，他们在寻找一种低级和肮脏的方式来共享代码直到建立企业 github 帐户时遇到了这个问题。
回答by Chris Maes
I have been messing around for a while to get a git server working with LDAP access, fine grained access control etc... Found a revelation: Use Gitlab:
我已经搞了一段时间让 git 服务器使用 LDAP 访问、细粒度访问控制等......发现一个启示：使用Gitlab：
- git repositories
- fine grained access (afaik gitlab uses gitolite under the hood)
- git 仓库
- 细粒度访问（afaik gitlab 在引擎盖下使用 gitolite）
if you want the quick and fast installation method: use the bitnami installer
如果你想要快速快速的安装方法：使用bitnami安装程序
