是否有人在实际项目中使用新的git super / subproject功能？它的效果如何？例如，据我所知，如果我推送到子项目，我必须手动调用superprojects钩子（可能使用子项目钩子，但仍然）？
答案 0 :(得分：13)
通过使用子模块，您将在Git工作区（意味着“超级项目”Git存储库）中定义配置。
“配置”是指“在工作区中工作所需的标签列表或SHA-1节点”
（通过工作，我的意思是你在工作区内做的“开发工作”：经典编译，补丁，合并，部署，或......）。
当您正在克隆一个超级项目并且“git update”您的子模块时就是这种情况：您正在检查先前在超级项目中提交的确切回购SHA1（记录为 gitlink 在the index）。
另一种模式是在一个或多个子模块上处理超级项目和时。
这意味着，对于给定的子模块，您已检出特定分支（您不再使用分离的HEAD作为该子模块的内容，而是指向分支尖端的指针）。
然后，“推送子模块”意味着更新包含该子模块的远程存储库（并且仅包含该子模块）。
最后一个场景中的实际技巧（可能需要一个你想要的钩子）是你推动超级项目的时候：你需要确保首先推送所有的子模块。
在将更改发布到引用它的超级项目之前，始终发布子模块更改。如果您忘记发布子模块更改，其他人将无法克隆存储库（超级项目）
答案 1 :(得分：12)
FWIW，我们正试图实现git的飞跃，而我们的项目（bitweaver，一个内容管理系统）是一个高度模块化的系统，nearly 160 repositories）。 “构建”通常包含二十二个或更多个子存储库。我们在CVS中使用了“虚拟模块”，这对我们来说非常有用，但是CVS对于提交提交有自己的限制。
Git子模块有一些严重的局限性，你肯定应该评估mercurial的实现，因为它对于外部/模块化项目来说肯定更友好和灵活（即它支持其他VCS系统，甚至是HgGit）。
以下是最大的挑战：
每个子模块都与a硬连接 当您在超级存储库中“git submodule add”时特别提交。这是 设计，并寻求作为一种利益 git维护者，所以我不希望它很快改变。这很痛苦 像我们这样提交的系统 总是发生在 子模块。你必须更新 超级项目，以跟上或更新 你的子回购后的主人 初始子模块更新。 （看到 以下是我们解决方案的超级目标。）
你不能轻易提交和推送 来自根的所有子回购。 这也很烦人，看 超级以下。
各种gotchas可能令人难以忍受，尤其是“无声地覆盖变化”的事情。
<强> supergit
我们写了shell script call supergit来处理一些痛苦。它一举完成了克隆，子模块初始化，更新和结帐大师。它还将单独执行git命令到super-repo中的所有目录（批量git处理各种类型）。
HTH，祝你好运。答案 2 :(得分：3)
如果你的意思是子模块，那肯定。
子模块不会也不应该知道它们在哪里被使用。例如，我有一个子模块用于我所知道的几个项目中（很可能是我不知道的几个项目）。
推送到子模块不会以任何方式影响包含子模块的项目使用的代码版本，所以我不确定你想要一个钩子做什么。