考虑使用git subtree。

使用git subtree，您将能够：

• 创建一个由子树组成的monorepo，每个子树都可以链接到单独的远程repo。
• 根据您的示例用例，承包商只能访问绑定到monorepo的单个子树的远程repo。*
• 拥有单一的聚合/统一历史（monorepo的要点）
• 从子树远程拉变更到monorepo
• 将monorepo的任何子树中所做的更改推到其单独的远程
• 保持简单/轻松的工作流程。

git subtree不要求存储库的用户学习任何新内容。他们可以忽略您正在使用git subtree来管理依赖项这一事实。”

关于优点/缺点的列表请查看Atlassian的Git subtree: the alternative to Git submodule，尽管我认为本文中的示例步骤相当有限，甚至有些过时。
逐步演示，每一步都有git log详细信息：

• Merging multiple repositories into a monorepo, while preserving history, using git subtree中的示例和步骤比Atlassian文章更简洁、更符合逻辑。
• git subtrees: a tutorial还包括了在monorepo中进行更改和推送到子树repo的逐步操作和结果，反之亦然，并给出了一些很好的提示。它确实提到了一个警告，那就是包含子树拉取的rebase不起作用。另一篇文章解释说，

不要试图改变它的基值，按原样推送它。如果你改变基值，当你下一次拉取子树时，git subtree将无法协调提交。
如果你必须做一个重定基，下面的Atlassian文章提供了一个变通方法。

• 我通常不喜欢看视频，但Introduction to Git Subtrees one看起来值得看，而且有很多细节。而且它比其他所有文章都更新（2019年）。提前看到你将要处理的内容会让人感到安慰。
  如果您想要私下了解：
• This excellent SO answer解释了git subtree和git subtree merge strategy（git merge -s subtree）之间的区别，本质上前者是在幕后使用后者，换句话说，git的概念是 * 瓷器 * vs * 管道 *。
• GitHub article about Git subtree merges使用合并策略（如果您喜欢这种方法）。
• A followup to the Atlassian article above获得更多“在git子树的引擎盖下”。
• Mastering Git subtrees也很好，它提到了一些您可能会或可能不会接受的其他细节，并且在我提供的所有链接中提供了最详细的分步操作和结果。
• 关于git subtree是如何产生的，它内部是如何工作的，以及子树如何优于子模块，请参见Git: submodules vs. subtrees。

monorepo-operator是一个可以让管理基于子树的monorepo更容易的工具。我没有用过它，也不能保证它，但是可能值得一试。

他们如何给予承包商只访问相关的客户端代码？
他们不会的。一个完整的单一责任公司的保密问题太重要了，不能被减轻。
Git本身也有no authorization (or authentication for that matter)。
意思是：再多的原生Git特性（子模块或子树）本身也不够。
我通常会看到一个中间门存储库，由承包商工作的相关部分组成，具有导入/导出工作的同步过程。
如果承包商远程工作，那么数据提取将托管在单独的服务器上，其本身在DMZ中管理，并复制到互联网上的外部服务器上，通过VPN访问？

我对monorepo不太确定，我知道这打破了monorepo的问题，但我能想到的一种方法是构建你的项目（如果可能的话）以支持模块并使用git子模块https://git-scm.com/book/en/v2/Git-Tools-Submodules
通过Git提供者的访问控制，例如Gitlab，Bitbucket等，你只能给予特定git子模块的访问权限授予承包者，无论是读/写权限还是管理权限。
以你的情况为例，你可以只放置设计层（一个与客户端共享在另一个存储库，并有它作为一个子模块到您的主存储库），如果你想更严格的安全性，如@VonC提到的，你可以设置一个VPN访问存储库为您的子模块。这可能需要时间来设置，但我认为这可能是值得的，一旦实现适当考虑到风险。