分布式版本控制系统中的差异化访问权限

Question

我目前在subversion下收集了大量工作，并整齐地组织在一个存储库中。当另一个人，比如X，需要与子项目合作，比如 /path/to/my/subproject，我可以简单地给予X在该特定路径读写的权限。从我的角度来看，我仍然拥有组织良好的存储库，并且不需要做任何其他事情，只需修改一些简单的权限，就可以让X使用 - 从X的角度来看，他只能访问相关部分。每个人都开心。

然而，在像git或Mercurial这样的分布式VCS中，所有访问似乎都是按存储库授予的。因此，我不知道如何在这些系统中获得与上述类似的功能。如果突然需要访问我原始存储库的某些部分，似乎我必须创建一个全新的存储库来让X访问。此外，如果另一个人，比如Y，需要在X可以访问的路径中获取其他访问权限，我会有问题。

我是否可以在分布式VCS中获得类似于subversion中具有不同访问权限的功能？如果可以，如何实现？

- someName

Answer 1

另一个选择是添加一个授权层，例如Gitolite。

它可以设置用户的授权：

• 贡献到Git repo的特定分支
• 和/或定义个人分支。

但更普遍的情况是，一个项目通常对应一个repo，以便该“组件”（“一致的文件集合”）可以独立于其他组件进行演进。
然后，您可以通过子模块将这些repo加入到一个父repo中。

缺乏身份验证和授权在“分布式版本控制系统和企业——良好的组合？”中有所解释。

- VonC

Answer 2

在Git或我所知道的任何其他分布式版本控制系统中都不可能实现。分布式版本控制系统的理念是去中心化一切，这意味着仓库没有中央身份验证。如果Joe克隆了你的仓库，他就可以完全访问整个仓库。现在你可以限制将什么内容拉入你的仓库，但他可以随心所欲地处理他自己的仓库。

有第三方解决方案，如Gitolite，可以让你接近你想要的行为，但需要设置服务器并跟踪密钥。这可能是值得的。

关键是，据我所知，没有办法限制对仓库子目录的读取权限。写入可以通过Gitolite或选择性地执行git fetch来处理，但一旦用户克隆了一个git仓库，他们在他们的计算机上拥有整个仓库的完全控制权。

从Gitolite手册中可以看到：

• 仓库级别的读取访问受控制
• 写入访问在分支/标签/文件/目录级别受控制，包括谁可以倒带、创建和删除分支/标签

- Andy