git - 你能直接在 Git 子模块中开发吗？

Question

我有两个项目(A 和 B)。他们都使用项目 Common。我想通过子模块将 Common 包含到 A 和 B 中，因为这样我就可以直接将 A 和 B 中的每个提交绑定(bind)到它们在 Common 中依赖的提交。

过去我试图让我的团队使用这样的子模块，但我们无法让它顺利工作。我们从子模块本身开发公共(public)代码并从子模块提交，但我们遇到了太多问题，以至于我们恢复到将所有项目放在同一目录下(C:\dev\A，C:\dev\Common)。

我很确定我们不知道子模块应该如何使用，但如果您不能直接在子模块中开发 Common 代码，那不会增加开发难度吗？有人可以解释一下子模块的正确用法吗？

Answer 1

您可以直接从子模块进行开发(正如我在“true nature of submodules”中所解释的那样)。
但是每次您在子模块中提交某些内容(并将其发布到某处)时，您需要确保在父存储库中也提交。

现在你有两个子模块组织:

• 递归包含

A
  Common
    (Common could depend itself on other dependencies)
B
  Common
    ...

• 或直接包含(仅限直接依赖项)

ParentA
   A
   Common
   Other A dependencies
ParentB
   B
   Common
   Other B dependencies

(实际上，如果 Common 有自己的依赖项，A 或 B 将依赖于“ParentCommon "这将引用 Common 及其所有直接依赖项)

除非你有一个结构命令，其中 Common 必须 是 A 的子目录，否则我会推荐第二种组织方式，它更接近于你的 C:\dev\A, C:\dev\Common 一个。

实际上，我只喜欢一个深度依赖项，对于ParentA，我列出了所有依赖项，直接的和间接的，作为子模块。

这是因为，对于任何试图管理依赖关系的工具，您仍然需要在以下方面做出决定:

• 依赖冲突(A 依赖于 X 需要 Z1，Y 需要 Z2 :您想在项目中使用/编译哪个版本的Z？)
• 依赖覆盖(当A依赖X需要Z1，而A也选择使用X2)
• 依赖循环(其中 A 依赖于 B，而 B 又依赖于 C，后者使用... A! )