有人真的在使用 git super/subprojects 吗？

Question

有人在实际项目中使用新的 git super/subproject 功能吗？效果如何？例如，我知道如果我推送到一个子项目，我必须手动调用 superprojects 钩子（也许使用 subprojects 钩子，但无论如何）？

Answer 1

通过使用子模块，您可以在 Git 工作区（即“超级项目”Git 存储库）中定义一个配置。
“配置”是指“在您的工作空间中工作所需的标签或 SHA-1 节点列表”。
（我所说的工作是指您在工作区中所做的任何“开发工作”：经典编译、补丁、合并、部署或......）。
当您正在克隆一个超级项目和“git update”您的子模块时就是这种情况：您正在检查先前在超级项目中提交的确切 repos SHA1（记录为 gitlink在the index)。

另一种模式是当您处理超级项目和一个或多个子模块时。
这意味着，对于给定的子模块，您已经签出了一个特定的分支（您不再使用分离的 HEAD 作为该子模块的内容，而是使用指向分支尖端的指针）。
然后，“推送子模块”意味着更新包含该子模块（并且只有那个）的远程存储库。

最后一个场景中的实际技巧（可能值得一试）是在您推送超级项目时：您需要确保首先推送所有子模块。

来自submodule tutorial：

始终在将更改发布到引用它的超级项目之前发布子模块更改。如果您忘记发布子模块更改，其他人将无法克隆（超级项目的）存储库

别忘了你can configure a submodule to follow a branch。

Answer 2

FWIW，我们正在尝试向 git 迈进，我们的项目（bitweaver，一个内容管理系统）是一个高度模块化的系统，带有nearly 160 repositories）。一个“构建”通常包含两打或更多子存储库。我们在 CVS 中使用了“虚拟模块”，这对我们来说非常有效，但是 CVS 对暂存提交有其自身的限制。

Git 子模块有一些严重的限制，您绝对应该评估 mercurial 的实现，因为它对于外部/模块化项目肯定更加友好和灵活（即它支持其他 VCS 系统，甚至 HgGit）。

以下是最大的挑战：

1. 每个子模块都硬链接到一个 当您在超级存储库中“git submodule add”时进行特定的提交。这是由 设计，并寻求作为一种利益 git 维护者，所以我不希望它很快改变。这是痛苦的 像我们这样的系统，其中提交的 总是发生在 子模块。你必须更新 超级项目跟上，或更新 您要掌握的子存储库 初始子模块更新。 （看 下面是我们的解决方案的supergit）。

2. 你不能轻易提交和推送到 所有子仓库都来自根目录。 这也很烦人，看 下面是supergit。

3. 各种gotchas 可能会令人难以忍受，尤其是“默默地覆盖更改”的事情。

超级git

我们写了一个shell script call supergit 来处理一些痛苦。它一口气完成了克隆、子模块初始化、更新和结帐主控。它还将单独对超级仓库中的所有目录执行 git 命令（各种批量 git 处理）。

HTH，祝你好运。

Answer 3

如果你指的是子模块，那当然。

子模块不知道也不应该知道它们在哪里被使用。例如，我有一个子模块用于我知道的几个项目中（很可能有几个我不知道）。

推送到子模块不会以任何方式影响包含子模块的项目所使用的代码版本，所以我不确定你想要一个钩子做什么。