我有一个项目，使用夫妇（现在~6）依赖（其他库）。他们中的大多数是在麻省理工学院/简化BSD许可证，所以它应该不是一个问题，只是复制到我的repo。
将所有这些库放到我的repo中并推送它们（当新版本到来时，也更新它们），或者我的项目repo应该只包含项目文件（代码，资产等），这是一个好的实践吗？
优点：
- 建筑是如此简单，因为我有我需要的一切总是关闭
- 添加的库意味着我使用这些版本测试了我的项目，因为其他版本（较旧/较新）可能会产生一些问题
缺点：
- 项目回购膨胀
- 我必须手动更新依赖项
- 如果我还想粘贴构建版本，我将不得不粘贴大量
- 文件，这将占用大量的空间，所以可能只坚持源代码？
- 有些库可能没有那么好许可证，直接使用它们（除了要求用户自己获得有效的库）并将它们放在我的repo中可能会带来一些麻烦
- 有更多的项目来保持依赖关系将意味着我必须同时为所有项目更新它们（例如，如果我使一些其他项目依赖于当前项目（它的库），那么它们都将具有相同的依赖关系）
1条答案
按热度按时间yizd12fk1#
简短回答：这要看情况。
长回答：
在您质疑是否应该将代码包含在存储库中之前，您应该先问一下是应该严格控制依赖关系还是应该放松一些。
这个问题的答案取决于您如何分发您的项目、您的客户/用户想要什么、您是否需要对依赖项进行任何源代码更改以及任何其他项目需求。
例如，假设您正在销售一个硬件设备，并且您的代码是该设备的固件，在这种情况下，您可能希望严格控制依赖项（需要非常特定的版本）。这使您可以完全控制整个系统，简化系统测试，如果您的设备需要满足某些安全、保密或可靠性要求，这一点非常重要（例如，发送到Pluto的医疗设备或探针）一般来说，如果您以二进制或文件系统映像的形式分发产品，您可能希望使用固定依赖项。
如果您希望用户能够动态链接到随其系统提供的任何版本的依赖项（这在很多方面都很有价值，包括安全更新），那么您可能希望放宽要求，明确支持哪些版本，将自己限制在这些版本中可用的API文档中，使用工具来强制执行要求（如果依赖项太旧，则会出现错误），并针对尽可能多的依赖项版本测试代码。
一旦你知道了你想要控制依赖项的严格程度，你就可以选择管理依赖项的机制，你可以使用像Apache Ivy这样的工具来自动获取依赖项，使用GNU Autoconf来强制执行特定的版本，或者你可以将代码拉入你的Git仓库并自己构建它，具体的选择并不重要;使用任何满足您的要求并且对您和您的用户最方便的内容。