GitHub monorepos 的精细读取访问权限

Posted 2023-02-27

【中文标题】GitHub monorepos 的精细读取访问权限

【英文标题】：Granular read access for GitHub monorepos

【发布时间】：2021-10-28 03:10:00

【问题描述】：

我们将向数百名用户提出数百个编码挑战。每个用户都可以针对任意数量的挑战发布自己的解决方案，从而可能产生数千个挑战解决方案。创建数百或数千个单独的存储库似乎很笨拙，因此我们希望将整个项目保留在一个单一存储库下，并限制每个用户在每个文件或每个目录的基础上的读取访问。每个用户应该只能看到自己的文件，而 repo 的所有者应该能够看到所有文件。

一个示例 repo 结构如下所示：

challenges/
├── challenge1/
│   ├── challenge1-user1/
│   ├── challenge1-user2/
│   └── challenge1-user5/
│       ...
├── challenge2/
│   ├── challenge2-user2/
│   └── challenge2-user3/
│       ...
├── challenge3/
│   ├── challenge3-user1/
│   ├── challenge3-user3/
│   └── challenge3-user4/
│       ...
├── ...
...

如果其他人不得不处理类似的问题及其解决方案，也很感兴趣。

【问题讨论】：

没办法。见***.com/a/59781833/7976758 见***.com/search?q=%5Bgithub%5D+read+access

【参考方案1】：

您不能提供对 Git 存储库的这种受限访问。 Git 命名空间的文档解释了原因：

获取和推送协议并非旨在防止一方从另一方存储库窃取不打算共享的数据。如果您有需要保护的私有数据免受恶意对等方的侵害，最好的选择是将其存储在另一个存储库中。这适用于客户端和服务器。特别是，服务器上的命名空间对读访问控制无效；您应该只向您信任的客户端授予对命名空间的读取权限，这些客户端具有对整个存储库的读取权限。

如文档所述，如果您的数据需要具有不同的访问控制，则它需要存在于不同的存储库中。 monorepo 在这里是行不通的。

【参考方案2】：

据我所知，github 不提供这种类型的功能，因为 github（以及一般的开源）是面向可见性和透明度的，提供这些功能没有多大意义。

我认为可以限制对主分支的推送，但允许人们使用他们的解决方案创建和推送他们自己的分支，并在删除其远程分支并将克隆存储在其他地方之前克隆每个分支。我不建议这样做，因为在推送分支和克隆和删除分支之间会有一些延迟，从而允许第三方也克隆其他用户的解决方案。

我想你可以通过github workflows 做到这一点；但是，这可能仍然不是一个理想的解决方案，也不是工作流最初设计的目的。