如何使 svn:externals 策略适应 git 子模块？
我无法弄清楚如何改变我的心态以使用 git，并遇到了以下问题。我遇到的情况是，我们有一个共享引擎和多个使用该引擎的项目。内部开发团队和第二方团队可能正在开发使用共享引擎的项目，并且希望在开发过程中尽可能多地使用共享引擎的 HEAD，直到发布前几周，共享引擎将被标记并分支，然后项目将使用该分支。项目团队通常一次只处理一个项目，但可能在调试或添加功能期间对共享引擎进行更改。当他们提交这些更改时，我们的构建系统会运行以查找他们在提交时可能引入的任何问题。
我（想我）想在新项目/新公司中使用相同的模型。在svn中，结构是这样的： 项 项目开发人员
project_in_dev-+
+- svn:external shared_engine:head
project_about_to_ship-+
+-svn:external shared_engine_rev1_branch
这非常有效：
- 项目开发人员可以执行一个命令来检查他们需要的所有依赖
- 可以完成引擎工作并轻松提交到共享引擎
- 我们可以轻松地修改或更改项目与外部一起使用的共享引擎 引擎更新
- 很容易通过日常“从根项目更新”获得
好的，现在我已经转移到 git，子模块似乎是处理外部代码的新方法，但似乎我失去了一些功能。
- 实际上获取项目的所有依赖项是一个多步骤的过程。项目开发人员必须执行 git clone 然后执行 git submodule init/git submodule update --recursive
- 这是一个更新根项目和子模块的多步骤过程，因此如果另一个开发人员对根项目进行了与更改匹配的更改子模块，您不会立即获得匹配的代码，并且可能会感到非常困惑
- 子模块被锁定到特定提交，如果您对子模块进行更改，您将很难使其与共享引擎的头一起
- 工作无法控制项目开发人员检查了共享引擎的哪个版本，而没有给出更新内容的说明
所以我的问题如下：
- 首先也是最重要的，上述关于子模块的假设是否正确？它似乎是基于我读过的内容，但我不是 100% 确定，因为我仍在弄清楚 git
- 如果我的假设是正确的，我是否用正确的过程来处理问题？使用git需要重新调整思路吗？换句话说，是否有另一种方法可以完成我正在尝试做的事情并且需要以不同的方式思考该过程？
- 假设我没有搞砸前两个，并且子模块不会做我想要的事情，那么什么会呢？我读到了有关子树合并的内容，但这些似乎也不完全正确，因为看起来我无法将对共享代码所做的更改返回到存储库。
非常感谢您的帮助和耐心。如果不是很明显，那么我对 git 还很陌生，我喜欢它并且想要拥抱它，但我仍然有一些概念上的误解，因为我可能因多年使用中央存储库而受到大脑损伤。我想学习！另外，我整天都在 rtfm'ing，并查看各种博客文章、stackoverflow 问题等，但我仍然不明白，我显然需要针对我的情况逐步阐明它。我没有同事可以问这个问题，西雅图地区有没有可能有 git 专家的用户组？ :)
I'm having trouble figuring out how to change my mindset to git and have run in to the following problem. I have the situation where we have a shared engine and multiple projects that use the engine. Internal development teams and second party teams may be working on projects that use the shared engine, and want to be using HEAD of the shared engine as much as possible during development, until just a few weeks before ship, where the shared engine will be tagged and branched, and the project will then use that branch. The project teams typically only work on one project at a time, but may make changes to the shared engine during debugging or to add features. When they commit those changes, our build system runs to find any problems they may have introduced with the commit.
I (think I) want to use this same model with a new project/new company. In svn, the structure was something like this:
shared_engine
project_in_dev-+
+- svn:external shared_engine:head
project_about_to_ship-+
+-svn:external shared_engine_rev1_branch
This worked very well:
- Project developers could do one command to check out all the dependencies they would need
- Project developers could do engine work and commit in to the shared engine easily
- We could easily rev or change the shared engine the project was using with externals and revisions
- Engine updates were easy to get with your daily "update from the root project"
OK, now I've moved to git, and submodules SEEM to be the new way to deal with external code, but it seems like I lose some features.
- It's a multiple step process to actually get all the dependencies of the project. Project developers have to do a git clone then a git submodule init/git submodule update --recursive
- It's a multiple step process to update the root project and the submodule, so if changes are made to the root project by another developer that match changes to the submodule, you don't get the matching code immediately and could get very confused
- The submodule is locked to a particular commit, and if you make changes to the submodule you will have trouble getting it to work with the head of the shared engine
- I have no control over what revision of the shared engine the project developer has checked out without giving instructions on what to update to
So my questions are as follows:
- First and foremost, are the above assumptions about submodules correct? It seems to be based on what I've read, but I'm not 100% certain as I'm still figuring out git
- If my assumptions are correct, am I approaching the problem with the correct process? Do I need to readjust my thinking when using git? In other words, is there another way to do what I'm trying to do and need to think about the process differently?
- Assuming I haven't blown the first two, and submodules won't do what I want, what will? I read about subtree merges but those don't seem exactly right either as it looks like I can't get changes made to the shared code back in to the repository.
Thanks so much for your help and patience. If it's not obvious, I'm very new to git, and I like it and want to embrace it, but I'm still having some conceptual misunderstandings because I've probably been brain damaged by years of using central repos. I want to learn! Also, I've been rtfm'ing all day, and looking at various blogs posts, stackoverflow questions, etc, and I still don't get it, I obviously need it spelled out step by step for my situation. I have no coworkers to ask about this, any user groups in the Seattle area where there might be some git gurus? :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你是对的，子模块总是引用特定的修订版本，当你
git add子模块目录时，它就被修复了（因此你可以准确控制开发人员签出的内容盒子）。但我认为这是一个功能，因为您始终可以在需要时请求子模块的 HEAD。另一方面，这意味着当您签出项目的旧状态时，无论子模块中发生了什么变化，您总是会得到相同的状态。您可以将它们视为固定到特定修订版的 svn 外部。至于子模块中的更改，它们只是普通的 git 存储库，您可以在其中使用正常的工作流程，就好像它们被克隆到自己的工作副本中一样。与常规克隆有一个区别，即子模块的签出很可能是一个分离的头，因此当您在其中进行更改时必须自己创建一个分支。
对于许多命令部分，是的，需要做更多的工作，这就是为此功能付出的代价。如果有很多子模块，您可以添加一个执行子模块签出的脚本。
编辑
我找到了有关子模块的详细解释： http://longair.net/blog/2010/06/02/git-submodules-explained/。
You are right that a submodule always references a specific revision, which is fixed when you
git addthe submodule directory (and therefore you can control exactly what is checked out on the developer box). But I see this as a feature, since you can always request the HEAD of a submodule when you need it. On the other side this means that you always get the same state when you checkout an old state of you project, regardless whatever changed in the submodules. You can think about them as svn externals which are pinned to a specific revision.As for changes in the submodule, they are just normal git repos, where you can work with your normal workflow, as if they where cloned into an own working copy. There is one difference to a regular clone, that the checkout of a submodule is very likely a detached head, so you must create a branch on your own when you do changes in there.
For the many commands part, yes, there is a need to do more work, that's the price to pay for this feature. You may add a script which performs the submodule checkout if there are many of them.
EDIT
I found a detailed explanation about submodules: http://longair.net/blog/2010/06/02/git-submodules-explained/.