如何使我的svn:externals策略适应git子模块？

我很难弄清楚如何将我的思维方式转变为git，并且遇到了以下问题。我的情况是，我们有一个共享引擎和多个使用该引擎的项目。内部开发团队和第二方团队可能正在处理使用共享引擎的项目，并希望在开发期间尽可能多地使用共享引擎的负责人，直到发布前几周，共享引擎将被标记和分支，然后项目将使用该分支。项目团队通常一次只处理一个项目，但可以在调试期间更改共享引擎或添加功能。当他们提交这些更改时，我们的构建系统将运行以查找他们在提交时可能引入的任何问题

我（想我）想在新项目/新公司中使用同样的模式。在svn中，结构如下所示： 共享引擎

project_in_dev-+
               +- svn:external shared_engine:head
project_about_to_ship-+
                      +-svn:external shared_engine_rev1_branch

这非常有效：

• 项目开发人员可以执行一个命令来检查他们需要的所有依赖项
• 项目开发人员可以轻松地完成引擎工作并投入到共享引擎中
• 我们可以很容易地对项目使用的共享引擎进行外部和修改
• 引擎更新很容易通过您的每日“根项目更新”获得

好的，现在我转到git，子模块似乎是处理外部代码的新方法，但我似乎失去了一些特性

• 这是一个多步骤的过程，实际获取项目的所有依赖项。项目开发人员必须先进行git克隆，然后进行git子模块init/git子模块更新——递归
• 更新根项目和子模块是一个多步骤的过程，因此，如果另一个开发人员对根项目进行的更改与子模块的更改相匹配，您不会立即获得匹配的代码，并且可能会非常困惑
• 子模块被锁定到一个特定的提交，如果您对子模块进行更改，您将很难让它与共享引擎的头一起工作
• 我无法控制项目开发人员签出的共享引擎的哪个版本，而没有给出更新内容的说明

因此，我的问题如下：

• 首先，上述关于子模块的假设是否正确？它似乎是基于我所读到的，但我不是100%确定，因为我仍然在计算git
• 如果我的假设是正确的，我是否用正确的流程处理问题？使用git时是否需要重新调整思维？换句话说，有没有其他方法来做我正在尝试做的事情，并且需要以不同的方式来思考这个过程
• 假设我没有破坏前两个，子模块不会做我想做的事情，那会怎样？我读过关于子树合并的文章，但这些看起来也不完全正确，因为看起来我无法将对共享代码所做的更改返回到存储库中

---

非常感谢你的帮助和耐心。如果不是很明显，我对git很陌生，我喜欢它并想接受它，但我仍然有一些概念上的误解，因为我可能因为多年使用中央回购而大脑受损。我想学习！而且，我整天都在rtfm'ing，看各种博客帖子、stackoverflow问题等等，但我还是不明白，我显然需要根据我的情况一步一步地把它说清楚。我没有同事可以问这个问题，西雅图地区的任何用户群都可能有一些git大师吗？：）

子模块总是引用特定的修订，这是正确的，当您添加子模块目录（因此您可以精确控制在开发者框中签出的内容）时，该修订是固定的。但我认为这是一个特性，因为在需要子模块时，您总是可以请求它的头。另一方面，这意味着您在签出项目的旧状态时总是获得相同的状态，而不管子模块中发生了什么更改。您可以将它们视为固定到特定修订版的svn外部

至于子模块中的更改，它们只是普通的git repo，您可以在其中使用正常的工作流，就像它们被克隆到自己的工作副本中一样。与常规克隆有一个区别，子模块的签出很可能是一个分离的头，因此当您在其中进行更改时，必须自己创建一个分支

对于许多命令部分，是的，需要做更多的工作，这是为此功能付出的代价。如果存在多个子模块签出，则可以添加执行子模块签出的脚本

编辑

---

我找到了关于子模块的详细解释：。

谢谢你的回答，它基本上证实了我的用例中子模块的局限性。脚本没有帮助，不幸的是，我有人在使用Ortoisegit，所以没有办法给他们一个脚本：（@Chris AFAIR TortoiseGIT也有一些与子模块相关的命令（现在无法检查，因为目前我没有运行windows）.值得注意的是，git 1.7添加了稀疏签出，这解决了我的一些问题。最大的问题是，让开发人员自动与我们在同一个库分支上工作仍然没有完全解决。感谢他们的回答，他们确实给了我关于在何处查找的想法，但我不能将两者都标记为真正的回答，但我正在投票：）