假设项目 X 是基础项目,项目 Y 依赖于 X。项目 Y 可能是项目 X 的插件,或者它可能是一个独立的应用程序,需要以其他方式使用项目 X。
我一直认为项目 Y 应该是超级项目,项目 X 应该是项目 Y 的子模块。
然而,在阅读本文时,似乎我的想法可能会颠倒过来。在本文中,依赖项是超级项目,依赖项代码(在本例中为插件)是子模块。那么这是使用子模块的正确方法吗?
假设项目 X 是基础项目,项目 Y 依赖于 X。项目 Y 可能是项目 X 的插件,或者它可能是一个独立的应用程序,需要以其他方式使用项目 X。
我一直认为项目 Y 应该是超级项目,项目 X 应该是项目 Y 的子模块。
然而,在阅读本文时,似乎我的想法可能会颠倒过来。在本文中,依赖项是超级项目,依赖项代码(在本例中为插件)是子模块。那么这是使用子模块的正确方法吗?
这取决于,但在一般情况下,我会说子模块是(或可以是)两者。
显然,如果项目 Y 是项目 X 的依赖项(例如,外部库),它应该是一个子模块。
但是子模块不仅用于依赖关系,还用于作为半独立开发的项目组件的项目。插件就是这样一个组件:它是独立开发的,但您可能希望将它与项目的源代码打包在一起。
如果 ProjectY 可以在不了解 ProjectX 的情况下生存(它可能是 X 的插件),它就不可能是一个超级项目。
如果它需要 X 以某种方式完成,那么是的,它可能是一个超级项目,以便在其树中引用 X(如子模块的真实性质中所述)。
在基于组件的方法中,真正的超级项目将是引用正确版本的 ProjectY和ProjectX 的第三个项目,以记录整个项目工作所需的确切配置(即修订列表)。
OP 添加了正确的问题:在哪里存储依赖关系(Y 对 X)?
如果采用基于组件的方法并且有一个 ProjectZ 超级项目,并且 ProjectY 依赖于 ProjectX 来构建,那么我们是否不将 ProjectX 作为子模块包含在 ProjectY 的存储库中,而仅包含在 ProjectZ 中?
这意味着 ProjectY 不能独立构建,使其(由于缺乏口才)成为一种“隐含的子模块”。
如果您只有 2 个组件,一个依赖于另一个,当然:您可以直接将 ProjectX 声明为 ProjectY 的子模块。
但是,如果 ProjectY 不能自行构建,那么它无论如何都不是一个“完整的”(如“自治”)项目。
因此,在 ProjectY 之外存储依赖信息的全局父“ProjectZ”具有其优势: