将所有项目依赖项放入项目的存储库中是好的做法吗？

Is putting all project dependencies inside project's repository good practice?

本文关键字：项目存储依赖更新时间：2023-10-16

我有一个项目，使用一对(目前~6)依赖关系(其他库)。它们中的大多数都是基于MIT/简化BSD许可证，所以把它们复制到我的repo应该没有问题。

将所有这些库放到我的repo中并推送它们(当新版本出现时，也更新它们)会是一个好的实践吗?或者我的项目仓库应该只包含项目文件(代码，资产等)?

优点:

的建设是如此简单，因为我有我所需要的一切总是关闭
添加的库意味着我使用这些版本测试了我的项目，因为其他版本(旧的/新的)可能会产生一些问题

缺点:

project repo臃肿
必须手动更新依赖项
如果我想粘贴也构建版本，我将不得不粘贴很多
文件，它会占用很多空间，所以可能坚持源代码只有吗?
一些库可能没有那么好的许可证，直接使用它们(而不是要求用户自己获得有效的库)并将它们放在我的repo中可能会产生一些麻烦
有更多的项目来保持依赖关系意味着我必须在同一时间为所有项目更新它们(例如，如果我根据当前项目(它的库)制作一些其他项目，那么它们都将具有相同的依赖关系)

简短的回答:看情况。

长答:

在你质疑在你的存储库中包含代码是否合适之前，你应该问一下是否应该严格控制依赖关系，或者更放松。

这个问题的答案取决于你如何发布你的项目，你的客户/用户想要什么，你是否需要对依赖项进行任何源代码更改，以及任何其他项目需求。

例如，假设您正在销售一个硬件设备，您的代码是该设备的固件。在这种情况下，您可能希望严格控制依赖关系(需要非常特定的版本)。这使您可以完全控制整个系统，从而简化了系统测试，如果您的设备需要满足某些安全、保障或可靠性要求(例如，它是一个医疗设备或发送到冥王星的探测器)，这一点非常重要。通常，如果您以二进制或文件系统映像的形式分发产品，则可能需要使用固定依赖项。

如果您希望用户能够动态链接到其系统附带的依赖项的任何版本(这在许多原因上都很有价值，包括安全更新)，那么您可能希望放宽要求。弄清楚支持哪些版本，限制自己使用这些版本中可用的文档api，使用工具来强制执行需求(如果依赖项太旧就会出错)，并针对尽可能多的依赖项版本测试代码。

一旦你知道你想要多么严格地控制你的依赖关系，你就可以选择用来管理它们的机制。您可以使用Apache Ivy之类的工具自动获取依赖项，GNU Autoconf强制执行特定版本，或者您可以将代码拉入Git存储库并自己构建它。具体的选择并不重要;

使用任何满足您的需求并且对您和您的用户最简单的方法。