我如何使我的svn：externals策略适应git子模块？ [英] How do I adapt my svn:externals strategy to git submodules?

问题描述

我无法弄清楚如何改变我的思维方式，并且遇到以下问题。我有这种情况，我们有一个共享引擎和多个使用引擎的项目。内部开发团队和第二方团队可能在使用共享引擎的项目上工作，并且希望在开发过程中尽可能多地使用共享引擎的HEAD，直到发布前几周才会共享引擎将被标记并分支，然后项目将使用该分支。项目团队一次只能在一个项目中工作，但可能会在调试过程中对共享引擎进行更改或添加功能。当他们提交这些更改时，我们的构建系统运行时会发现他们可能在提交时引入的任何问题。

我（想我）想要使用同一个模型新项目/新公司。在svn中，结构如下所示：
shared_engine

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

这很有效：

• 项目开发人员可以执行一个命令来检查他们需要的所有依赖关系。
  
• 项目开发人员可以轻松完成引擎工作并提交给共享引擎


• 我们可以通过外部和修订轻松地转换或更改项目使用的共享引擎


• 发动机更新很容易在每日从根项目更新中获得

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

• 实际获得所有依赖关系是一个多步骤过程该项目的s。项目开发人员必须做一个git clone然后一个git子模块init / git submodule update --recursive


• 更新根项目和子模块是一个多步骤过程，所以如果进行更改由其他开发人员向根项目添加匹配对子模块的更改，您不会立即得到匹配的代码，并且可能会非常困惑


• 子模块已锁定到特定的提交，并且if您对子模块进行更改时，无法使其与共享引擎的头部一起工作


• 我无法控制项目开发人员已经检出的共享引擎的修订版本
  $ b

  所以我的问题如下：
  
  

  
  
  • 首先，关于子模块的上述假设是否正确？这似乎是基于我读过的内容，但我不是100％确定的，因为我还在搞清楚git
  
  
  • 如果我的假设是正确的，我是否接近问题正确的过程？在使用git时，我需要重新调整思路吗？换句话说，是否有另一种方法来做我想做的事情，并且需要以不同的方式思考这个过程？
  
  
  • 假设我没有吹掉前两个，子模块获胜不做我想要的，会怎样？我阅读了有关子树合并的内容，但这些看起来并不完全正确，因为看起来我无法将共享代码所做的更改返回到存储库。
  
  
  
  
  

  非常感谢您的帮助和耐心。如果不是很明显，我对git很陌生，我喜欢它，并且想拥抱它，但是我仍然有一些概念误解，因为我可能因为使用中央回购多年而被脑损坏。我想学习！另外，我一整天都在忙碌着，看着各种博客帖子，stackoverflow问题等，但我仍然没有得到它，我显然需要它为我的情况一步步拼写出来。我没有同事问过这个问题，西雅图地区的任何用户群可能会有一些git大师？ ：）

  解决方案

  你是对的，一个子模块总是引用一个特定的修订版本，当你 git add 子模块目录（因此，您可以精确地控制在开发者框中签出的内容）。但是我将其视为一项功能，因为您可以随时在需要时请求子模块的HEAD。另一方面，这意味着当您签出项目的旧状态时，无论子模块中发生了什么变化，您总能得到相同的状态。你可以把它们想象成svn externals，它被固定在一个特定的版本上。
  
  

  至于子模块的变化，它们只是普通的git repos，你可以在那里工作你的正常工作流程，就好像它们被克隆到自己的工作副本中一样。与常规克隆有一个区别，即子模块的签出很可能是分离的头部，所以当您在那里进行更改时，您必须自己创建一个分支。

  
  
  对于许多命令部分来说，是的，需要做更多的工作，这是为这个功能付出的代价。
  
  

  编辑

  
  $ b您可以添加执行子模块结帐的脚本。 $ b

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

  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? :)

  解决方案

  You are right that a submodule always references a specific revision, which is fixed when you git add the 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/.

  这篇关于我如何使我的svn：externals策略适应git子模块？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！