可以直接在Git子模块中开发吗？

Question

我有两个项目（A 和 B）。他们都使用 Common 项目。我想将 Common 包含到 A & 中B 通过子模块，因为这样我就可以直接将 A 和 B 中的每个提交绑定在一起。 B 他们共同依赖的承诺。

过去我试图让我的团队使用这样的子模块，但我们无法让它顺利工作。我们正在从子模块本身内部开发通用代码&从子模块提交，但我们遇到了很多问题，因此我们恢复将所有项目都放在同一目录下（C:\dev\A、C:\dev\Common）。

我很确定我们不知道子模块应该如何使用，但是如果你不能直接在子模块中开发公共代码，那不是会让开发变得更加困难吗？有人可以解释一下子模块的正确用法吗？

Answer 1

您可以直接从子模块进行开发（正如我在“子模块的真实性质”中解释的那样） ).
但是每次您在子模块中提交某些内容（并将其发布到某个地方）时，您都需要确保也在父存储库中提交。

现在您有两个子模块组织：

• 递归包含

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

• 或直接包含（仅直接依赖项）

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

（实际上，如果Common有自己的依赖项，< code>A 或 B 将依赖于“ParentCommon”，它将引用 Common 及其所有直接依赖项）

除非您有一个结构命令，其中 Common 必须 是 A 的子目录，我会推荐第二个组织，它更接近于您的 C： \dev\A、C:\dev\Common 一个。

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

这是因为，对于任何尝试管理依赖项的工具，您仍然需要做出以下决策：

• 依赖项冲突（A 依赖于 X，它需要 Z1 和需要 Z2 的 Y：您想在项目中使用/编译哪个版本的 Z？）
• 依赖项覆盖（当A 依赖于 X，它需要 Z1，而 A 也选择使用 X2 )
• 依赖关系循环（其中 A 依赖于 B，而 B 又依赖于 C，而 C 使用...A！）

Answer 2

子模块并不是像您在这里所希望的那样工作得特别顺利。您可能已经注意到，要在子模块中提交对项目的更改（从 Git v1.7 开始，可能是永久的），您需要：

1. 在子模块中进行更改。
2. 提交到子模块，获取新的 SHA 哈希值。
3. 使用新哈希更新外部项目的 .gitmodules 文件。
4. 致力于外部项目。

如果您要同步开发子模块和外部项目，这会很麻烦。就混合代码库时更喜欢稳定的软件配置而不是简单性而言，这是“正确的方法”，但在这种情况下命令序列异常长。

然而，弹出原因堆栈，使用子模块进行同步开发可能表明了几个更大的问题之一：

• 您的子组件之间没有清晰的接口，并且实现细节会跨越边界泄漏。
• 您的子组件没有经过深思熟虑的接口，因此在解决更有趣的问题时，您必须不断地重新发明东西。
• 您的界面稳定且高质量，但您对子模块代码没有良好的质量检查流程，因此您在尝试完成其他工作的同时不断修复该问题。
• （特别是如果A和B不断改变不同的东西）你的“公共”代码实际上比你想象的要小得多，或者应该以不同的方式划分。

这些情况都不一定适合您，但这些问题是导致您遇到可怕的锁步子模块更新工作流程的问题之一。当您几乎可以依赖共享库和头文件时，子模块工作得很好，但是有一些令人信服的原因（例如，必须一致的奇怪的编译标志）需要从源代码进行编译。我的方法是解决这些问题（如果它们是真正的根本原因）。

但是，如果不存在这些问题，可能是 git 不适合您。说起来我很痛苦，但这绝对是一种可能性。