你能直接用Git子模块开发吗？

Question

我有两个项目（A＆amp; B）。他们都使用项目Common。我想将Common纳入A＆amp; B通过子模块因为我可以直接将每个提交绑定在A＆amp;他们在Common中依赖的提交。

在过去，我试图让我的团队使用这样的子模块，但我们无法让它顺利运行。我们正在从子模块本身和开发中开发公共代码。从子模块提交，但我们遇到了很多问题，我们恢复了所有项目在同一目录下（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的{​​{1}}和需要Z1的{​​{1}}：Y的哪个版本想在你的项目中使用/编译？）
• 依赖关系覆盖（Z2取决于需要Z的{​​{1}}，而A也选择使用X）
• 依赖关系周期（其中Z1取决于A，X2依赖A使用... B！）

Answer 2

子模块不是特别顺畅的，就像你想要的那样。您可能已经注意到，要在子模块中提交项目的更改（从Git v1.7开始，可能是永久性的），您需要：

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

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

弹出为什么堆栈，但子步骤的锁步开发可能表示几个较大的问题之一：

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

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

如果不存在这些问题，可能是git对你来说是错误的工具。我很难说，但这绝对是可能的。