Answers:
使用git或mercurial等dvc将项目置于版本控制下。将共享代码置于git的子模块中。在需要它的项目中使用子模块。更新子模块时，可以使用单个命令将更改拉到其他项目。
还没有人提到双刃剑，所以我加2美分。如果您有多个项目，并且它们都共享一些可重用的代码，那么根据良好的编程习惯/原理（例如DRY），您应该将代码放在一个全局位置并以某种方式对其进行结构化，以便所有人都可以共享您的项目，无需任何修改。换句话说，将接口定义为通用且足够通用以适合所有人。
执行此操作的选项很少：1）创建其他人依赖的基础项目。该项目可以创建其他项目使用的二进制发行版。2）在您的组织内建立一个开源模型。将通用代码作为自己的代码分支，并让其他项目以与从任何OSS在线获取源代码相同的方式提取代码。
现在这是剑进来的地方...
将代码放置到其他项目/人员所依赖的公共位置可能会变得相当昂贵。假设您有一段代码，其他4个项目也依赖于此。您的一个使用项目A的客户发现了一个错误，因此您必须进行修复。您赶紧解决问题，并且该客户满意。但是您刚刚修改了其他3个项目所依赖的一些代码。您是否对所有这些进行了重新测试以确保未引入边缘条件？
通用代码还必须更加精心设计，模块接口也必须设计得更好，因为该代码必须容纳一个客户端，而不能容纳4个客户端，并且每个客户端可能只使用此代码，差别很小。
如果您的项目处于不同的发布周期，则在管理通用代码时需要更加小心。如果您距离切割项目C的最终图像还有3天的时间，那么您不能简单地更改公共代码，因为项目B需要新功能。
我并不是说公共库不是正确的解决方案。我是DRY的坚决支持者，并且我之前已经创建并支持通用代码，并将继续这样做。只是想说明一下，仅使代码通用将需要自己承担费用。
如果您是唯一重用此代码的人，那还不错。如果您有一个工程师团队，并且他们开始使用通用代码，那么支出会更多。如果涉及到其他人，则将代码放入一个公共库所花费的时间将是使它达到“完整”状态所花费的时间的三倍。您将需要a）使库更强大，以防止各种边缘条件和无效使用； b）提供文档，以便其他人可以使用该库； c）帮助其他人以您自己的方式使用库时进行调试没想到，您的文档也没有涵盖他们的特定用例。
我可以提供一些建议：
这是一个理想的解决方案，可能需要花一些精力才能开始工作。
DRY原则指出，应该有一个权威的真理来源。这要求所有程序逻辑都使用单个源存储库，而没有重复。整理文件以促进文档的共享和重用。
在分布式，多团队环境中进行沟通的务实要求表明，应该有多个独立的存储库，每个项目或协作一个。
我将通过不可避免的方法来解决这个问题：您将需要同时采用这两种方法，并且我们将使用脚本和自动化来解决这些方法相互矛盾的事实。
:-)
一个统一的存储库将成为您的唯一权威来源。每个项目的构建过程会将该项目使用的所有文件（仅这些文件）复制到一个中间位置，然后从该中间位置进行构建。（Unison或某些类似工具可用于移动增量而不是整个文件）。
这些中间位置可用作辅助，派生或下游存储库集的本地工作副本。权威存储库中的提交后钩子脚本将更新所有中间位置，并依次检查每个中间位置是否已更改，如果检测到更改，则对相应的辅助存储库进行相同的提交。
这样，多个辅助存储库与单个权威源存储库保持同步，并且构建过程确保了辅助存储库包含所有（可能是共享的）文档以及构建成功所需的其他文件。最后，最重要的是，开发和构建过程可确保仅在一处和一个地方编辑文件，并确保所有副本保持一致并保持最新。