3

假设项目 X 是基础项目，项目 Y 依赖于 X。项目 Y 可能是项目 X 的​​插件，或者它可能是一个独立的应用程序，需要以其他方式使用项目 X。

我一直认为项目 Y 应该是超级项目，项目 X 应该是项目 Y 的子模块。

然而，在阅读本文时，似乎我的想法可能会颠倒过来。在本文中，依赖项是超级项目，依赖项代码（在本例中为插件）是子模块。那么这是使用子模块的正确方法吗？

4

2 回答 2

3

这取决于，但在一般情况下，我会说子模块是（或可以是）两者。

显然，如果项目 Y 是项目 X 的​​依赖项（例如，外部库），它应该是一个子模块。

但是子模块不仅用于依赖关系，还用于作为半独立开发的项目组件的项目。插件就是这样一个组件：它是独立开发的，但您可能希望将它与项目的源代码打包在一起。

于 2010-07-15T02:19:40.730 回答
2

如果 ProjectY 可以在不了解 ProjectX 的情况下生存（它可能是 X 的插件），它就不可能是一个超级项目。

如果它需要 X 以某种方式完成，那么是的，它可能是一个超级项目，以便在其树中引用 X（如子模块的真实性质中所述）。

在基于组件的方法中，真正的超级项目将是引用正确版本的 ProjectY和ProjectX 的第三个项目，以记录整个项目工作所需的确切配置（即修订列表）。

OP 添加了正确的问题：在哪里存储依赖关系（Y 对 X）？

如果采用基于组件的方法并且有一个 ProjectZ 超级项目，并且 ProjectY 依赖于 ProjectX 来构建，那么我们是否不将 ProjectX 作为子模块包含在 ProjectY 的存储库中，而仅包含在 ProjectZ 中？
这意味着 ProjectY 不能独立构建，使其（由于缺乏口才）成为一种“隐含的子模块”。

如果您只有 2 个组件，一个依赖于另一个，当然：您可以直接将 ProjectX 声明为 ProjectY 的子模块。

但是，如果 ProjectY 不能自行构建，那么它无论如何都不是一个“完整的”（如“自治”）项目。
因此，在 ProjectY 之外存储依赖信息的全局父“ProjectZ”具有其优势：

  1. 直接从 ProjectZ 根目录使每个模块路径更加可见（而不是将 ProjectX 隐藏在 ProjectY 的深处，从而使 ProjectY 客户端不那么可见该依赖项）
  2. 统一 ProjectX 版本（如果多个模块需要 ProjectX，在 ProjectZ 中引用一次，清楚地宣传所有其他模块应该使用的 ProjectX 的“一个正式版本”）
于 2010-07-15T04:12:48.203 回答