gitolite或gitosis:存储库内目录的权限

3
例如:我有一个名为repo1的代码仓库,它的文件系统层次结构如下。
repo1:
 js
 html
 php/core
 php/menu

我想赋予自由职业者对repo1:php/menu的RW权限,但是对于所有的repo1,这个自由职业者只能拥有只读权限。

我能用gitolite或gitosis或其他什么方式实现吗?

3个回答

6

DVCS上的存储库访问权限始终与整个存储库相关联,而不是其中的一部分,这主要是因为您克隆了所有内容(浅克隆很困难)。

这意味着gitolite(我甚至不会提到已过时的gitosis)可以对以下内容进行限制:

  • 访问整个存储库
  • 仅写入某些分支(但无法限制对某些分支的读取访问权限)

它无法阻止用户访问存储库的某些部分

然而,自从gitolite v3或'g3'(2012年4月17日)以来,您可以使用VREF规则防止写入(推送到)某些目录(除了某些分支)。

原始答案 (gitolite V2或'g2', 2011年11月)

请参见 gitolite.conf -- 举例说明附注:"R"权限用于引用

repo    gitolite-admin
        RW+                 =   sitaram
        # this is equivalent to:
        RW+     refs/.*     =   sitaram

Sitaram 是唯一的管理员。他可以在 gitolite-admin 存储库中推送、创建、删除或回滚任何分支或标签。
        R master    =   wally       # MEANINGLESS!  WILL NOT DO WHAT YOU THINK IT DOES!

这样做不起作用。
你只能在仓库级别限制“读”访问,而不能在分支级别进行限制
这是一个Git问题,而不是一个gitolite问题。去打扰他们,或者切换到gerrit。

鉴于Gerrit也是基于Git的,这表明实际上可以解决这个问题。 - Jan Hudec
@JanHudec - 引用自Gitolite... "与此同时,那些迫切需要这个功能的人被引导到gerrit,因为他们有自己的git堆栈,不使用由Linus编写并由Junio维护的堆栈。对于原生的git堆栈,最好的解决方案是创建第二个仓库,并将其用于更“机密”的分支。" - Ash
你对于读取权限是正确的。它只能在仓库级别上授予,但写入访问权限可以在分支和标签级别上进行控制。 - Ash
@Ashley:嗯,那句话完全是胡说八道。Java 的重新实现不可能比 C 的实现更强大。 - Jan Hudec
这不是任何人的问题。这是一个可能被添加到gitolite的功能。只是它并没有那么多意义,所以没有人去做。 - Jan Hudec

0

0

首先,问题是在git的上下文中,“只读”和“读写”是什么意思。“写”在git中由两个不同的操作组成。“提交”创建了一个跨越整个树的修订版本(git根本没有任何每个文件的历史记录),而“推送”则将该修订版本复制到您的中央存储库。

没有办法限制“提交”仅供您自己使用,因为用户必须手动将任何钩子安装到他们的工作存储库中。所以,相关用户将能够创建修改任何内容的提交。他们还可以通过发送补丁、包或允许其他团队成员直接从工作存储库中拉取来与其他团队成员共享该提交。

你可以限制的是对中央仓库的“推送”。你可以创建一个updatepre-receive钩子(它们只在调用约定上有所不同),检查修订内容并拒绝它们,如果它们触及到你不想要的东西。 update钩子接收3个参数:分支名称、旧提交和新提交,因此你只需要git diff --name-status旧提交和新提交,如果给定的用户(你需要查找如何从gitolite获取)正在进行推送,并且更改影响除了你允许的子目录之外的其他内容,则拒绝推送。

用户仍然可以编写影响树的其他部分并通过让其他人推送将其放入主干。这可能很有用,但你的同事需要知道他们应该审查直接从顾问那里拉取的更改。

请注意,检查提交作者或提交者并不安全,因为作者可以自由设置。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接