包管理器与 Git 子模块/子树答案

【问题标题】：Package Manager vs. Git Submodule/Subtree包管理器与 Git 子模块/子树
【发布时间】：2018-09-10 11:07:43
【问题描述】：

是否有任何理由使用包管理器而不是 git 子模块/子树，反之亦然？ git 解决方案似乎比简单的包管理器要麻烦得多。

假设 git 子模块节省空间的好处并不重要。

更新：有人在这个问题中添加了一个 C++ 标签，但我已经删除了它。这个问题与 C++ 无关。欢迎提供比已接受答案更一般的答案。

【问题讨论】：

我认为使用某种包管理器比 git 子模块/子树更简单... C#(nuget)、node(npm) 或 rust(cargo) 等语言中的依赖项永远不会被复制，只有文件具有依赖项列表在 repo 中
我认为您的问题与这里的 C/C++ 项目有关？
@Konrad 不，我问的是一般的包管理器。
关于麻烦，它可以去任何一种方式。如果您的主要目标只是模块化您的代码库，那么包管理器实际上可能需要更多的工作。然后你必须处理每个模块的版本。

标签： git git-submodules package-managers git-subtree

【解决方案1】：

git 解决方案似乎比简单的包管理器要麻烦得多。

这与麻烦无关。

这是关于构建项目的两种不同方式：

通过二进制依赖项，使用包管理器（Nexus 或 Conan for C++：您声明您的依赖项，包管理器获取它们并在编译期间使用它们。
这就是 pom.xml 或 npm-package.json：在您的唯一代码库中再添加一个文件，它将指示编译器下载相关依赖项
通过 source 依赖项，使用 Git 子模块或子树，您可以在其中存储对其他源代码的引用、导入它们并重新编译所有内容。
例如，如果您的系统由一个前端 GUI 源和一个后端源组成，您可以在一个父项目存储库中引用这两个存储库，将它们的源合并到一个代码库中。

第一个在构建系统时很好，其中每个部分都有自己的发布生命周期，并且您希望依赖于预先构建的依赖项。

当依赖项与主程序更紧密地链接时，使用第二个。

或者当没有二进制依赖项时（例如，Go 和 its modules 就是这种情况）。

【讨论】：

更紧密的联系是什么意思？
二进制依赖是指链接到预先构建的静态或动态库？
@Konrad “紧密链接”的意思是：你不能在不修改依赖项的情况下修改主项目。在这种情况下，最好重新编译所有内容。
@Konrad 是的，预构建的，这意味着您可以对您的项目进行许多改进，但需要 same 依赖项：在这种情况下无需重新编译所有内容。预构建的工件就足够了，可以在一个小文本文件中声明，然后从工件存储库中获取，正如我在答案中提到的那样。
我其实不知道有些包管理器会在编译过程中获取包！我曾经有过的唯一经验是在您声明依赖项的第二次将包添加到源代码中。

【解决方案2】：

“如果技术环境允许打包和正式的依赖管理，你绝对应该走这条路。”

以上内容来自Mastering Git submodules，这是一篇写得很好且经过深思熟虑的文章，它应该成为这个问题和许多类似 Stackoverflow 问题的最佳答案。

让我引用与这个问题相关的部分：

它们是适合这项工作的工具吗？

在许多情况下，模块代码必须物理存在于容器代码中，通常是因为所使用的技术或框架。例如，用于 Wordpress、Magento 等的主题和插件实际上通常只存在于项目树中的常规位置，而这是“安装”它们的唯一方法。

在这种情况下，使用子模块（或子树）可能是正确的解决方案，前提是您确实需要对该代码进行版本化并与第三方围绕它进行协作（或将其部署在另一台机器上）；对于严格本地化、未版本化的情况，符号链接可能就足够了，但这不是本文要讨论的内容。

另一方面，如果技术环境允许打包和正式的依赖管理，那么您绝对应该选择这条路：它可以让您更好地拆分代码库，避免一些副作用和陷阱，这些副作用和陷阱会乱扔子模块空间，并让您受益于版本控制方案，例如为您的依赖项提供语义版本控制 (semver)。

【讨论】：

答案是重点，并提供了一个很好的链接以供进一步阅读。谢谢！
请注意这篇文章，它有点过时了，而且并非其中的所有内容都是真实的。例如，git pull 学习了 --recurse-submodules，因为它被编写了。
@philb 当然，任何关于 git 命令缺点的文章都是如此，因为 git 的发展相当迅速。但它提出的回答上述 SO 问题的论点完全不依赖于 git 缺陷，而是依赖于包管理器和 git 子模块/子树之间的根本差异。这不会改变。