svn - 我如何调整我的 svn :externals strategy to git submodules?

Question

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

我(认为我)想在新项目/新公司中使用相同的模型。在 svn 中，结构是这样的:共享引擎

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

这很有效:

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

好的，现在我已经转移到 git，子模块 SEEM 成为处理外部代码的新方法，但似乎我失去了一些功能。

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

所以我的问题如下:

• 首先，上述关于子模块的假设是否正确？这似乎是基于我读过的内容，但我不是 100% 确定，因为我还在弄清楚 git
• 如果我的假设是正确的，我是不是在用正确的流程解决问题？使用git需要重新调整思路吗？换句话说，是否有另一种方法来完成我正在尝试做的事情并且需要以不同的方式考虑流程？
• 假设我没有搞砸前两个，子模块不会做我想做的事，那什么会呢？我阅读了有关子树 merge 的内容，但这些内容似乎也不完全正确，因为看起来我无法将对共享代码所做的更改返回到存储库中。

非常感谢您的帮助和耐心等待。如果不是很明显，我是 git 的新手，我喜欢它并想拥抱它，但我仍然有一些概念上的误解，因为我可能已经被多年使用中央仓库的大脑损坏了。我想学习!另外，我整天都在 rtfm'ing，查看各种博客文章、stackoverflow 问题等，但我仍然不明白，我显然需要根据我的情况逐步说明。我没有同事问这个问题，西雅图地区的任何用户组可能有一些 git 专家？ :)

Answer 1

你是对的，一个子模块总是引用一个特定的修订，当你 git add 子模块目录时它是固定的(因此你可以控制完全 checkout 的内容在显影盒上)。但我将此视为一项功能，因为您始终可以在需要时请求子模块的 HEAD。另一方面，这意味着当您检查项目的旧状态时，无论子模块中发生了什么变化，您总是会得到相同的状态。您可以将它们视为固定到特定修订版的 svn 外部组件。

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

对于许多命令部分，是的，需要做更多的工作，这是为此功能付出的代价。如果有很多子模块，您可以添加一个脚本来执行子模块检查。

编辑

我找到了关于子模块的详细解释:http://longair.net/blog/2010/06/02/git-submodules-explained/ .