我一直在阅读有关 monorepos 的优点，但还没有找到解决共享部分 repo问题的缓解方法：
假设一个组织有一个用于客户端/服务器 Web 应用程序的 monorepo。他们聘请承包商来设计客户的某些部分。他们如何才能让承包商只访问相关的客户代码？即使是稀疏的结帐也不是微不足道的。
问问题
2292 次
3 回答
8
考虑使用git subtree.
与git subtree您一起，您将能够：
创建一个由子树组成的 monorepo，每个子树都可以链接到单独的远程仓库。
给定您的示例用例，承包商将只能访问绑定到 monorepo 的单个子树的远程存储库。
有一个单一的聚合/统一历史（monorepo 的点）
将子树远程的更改拉入 monorepo
将 monorepo 的任何子树中所做的更改推送到其单独的远程
保持简单/容易的工作流程。
git subtree不需要您的存储库的用户学习任何新内容。git subtree他们可以忽略您用来管理依赖项的事实。”
有关优点/缺点的列表，请查看 Atlassian 的Git 子树：Git submodule 的替代品。尽管我认为本文中的示例步骤如果不是过时的话，也是相当有限的。
git log有关每一步详细信息的分步演示：
- Merging multiple repositories into a monorepo，同时保留历史，使用
git subtree中的示例和步骤比 Atlassian 文章更简洁、更合乎逻辑。 git subtrees：一个教程还包括在monorepo中进行更改和推送到子树repo的逐步操作和结果，反之亦然，并提供了一些很好的提示。它确实提到了一个警告，那就是包含子树拉取的 rebase 不起作用。另一个帖子解释说，
不要试图改变这个。按原样推。如果你变基，当你进行下一次子树拉取时， git subtree 将无法协调提交。
如果您必须进行变基，我在下面链接的后续 Atlassian 文章提供了一种解决方法。
- 我通常讨厌看视频，但Git 子树简介 看起来很值得，而且有很多细节。它也比所有其他文章更新得多（2019 年）。提前看到你将要处理的事情是令人欣慰的。
如果您想要了解以下内容：
- 这个优秀的 SO 答案
git subtree解释了git子树合并策略(git merge -s subtree)之间的区别。本质上前者在幕后使用后者。换句话说，git 的瓷器与管道的概念。 - 如果您更喜欢这种方法，则有关 Git 子树合并的 GitHub 文章会使用合并策略。
- 对上述 Atlassian 文章的后续文章获得了更多“在 git subtree 的幕后”。
- 掌握 Git 子树也很好，它提到了一些您可能认为或可能不接受的其他细节，并且包含我提供的所有链接中最详细的分步操作和结果。
- 有关如何产生的一些历史
git subtree，以及它如何在内部工作，以及子树如何优于子模块，请参阅 Git：子模块与子树。
monorepo-operator 是一个工具，可以让你更轻松地管理基于子树的 monorepo。我没有使用它，也不能保证它，但可能值得一试。
于 2020-04-17T14:08:30.320 回答
2
他们如何才能让承包商只访问相关的客户代码？
他们没有。完整的单一仓库的机密性问题太重要了，无法缓解。
而且 Git 本身没有授权（或身份验证）。
含义：仅靠本地 Git 功能（子模块或子树）是不够的。
我通常会看到一个中间门存储库，由承包商工作的相关部分组成，具有导入/导出工作的同步过程。
如果该承包商在远程工作，那么该数据提取将托管在单独的服务器上，该服务器本身在DMZ中管理，并复制到 Internet 上的外部服务器，通过 VPN 访问？
于 2019-02-24T03:16:47.923 回答
0
我不确定monorepo，我知道这打破了monorepo问题，但我能想到的一种方法是构建你的项目（如果可能的话）以支持模块并使用git子模块https://git-scm.com/book /en/v2/Git-工具-子模块
通过 git 提供者的访问控制，例如 Gitlab、Bitbucket 等，您只能向承包商授予对特定 git 子模块的访问权限，无论是读/写还是管理员访问。
例如，在您的情况下，您可以将设计层（与客户端共享的另一个存储库中的层，并将其作为主存储库的子模块），如果您想要更严格的安全性，如@VonC 提到的，您可以设置一个 VPN访问您的子模块的存储库。设置可能需要时间，但我认为考虑到风险，一旦正确实施，它可能是值得的。
于 2020-04-22T03:40:29.217 回答