Git：合并和子模块 [英] Git: Merging and Submodules

问题描述

可以说我在RepoX中有两个分支叫做BranchA和BranchB。 RepoX还有一个名为SubmoduleY的子模块。

BranchA在修订版'abc'中有SubmoduleY，BranchB在修订版'def'中有SubmoduleY。

假设我想将BranchA合并到BranchB中，但我想离开BranchB的SubmoduleY指向它的原始版本'def'。我看到了一些方法：

方法1：

1. 结帐BranchB。


2. 将SubmoduleY移动到修订版'abc'以使实际合并变得无痛苦（我们现在不想在子模块级别进行任何合并）。


3. 提交SubmoduleY的新版本（我们不能让它为合并浮动）。


4. 将BranchA合并到BranchB中。解决所有冲突。
   
5. 将SubmoduleY移回到修订版本'def'。


6. 提交SubmoduleY的新版本。


$ b

方法2：

与方法1相同，但不是执行第6步，重新绑定并从步骤3中删除额外的子模块提交。

这两种方法似乎都有恼人的缺点： / b>

方法1将两个额外的提交放入历史记录中。

方法2忘记了对子模块修订所做的任何更改，因为这些更改提交被删除。因此，以后的任何合并都将不得不再次处理一些问题。

有没有更好的方法？

解决方案

你可以在你的方法1上做一个变体，但是用来修改子模块版本（在步骤6中） / code>，以便它更改合并提交中子模块的状态。换句话说，这将是：



  $ git checkout b 
 $ git merge a 
合并通过递归。 
 example.txt | 1 + 
 sY | 2 +  -  
 2个文件已更改，2个插入（+），1个删除（ - ）
创建模式100644 example.txt 
 $ cd sY 
 $ git checkout def 
 [...你得到分离的HEAD警告..​​.] 
 $ cd .. 
 $ git add sY 
 $ git commit --amend 
  

请注意，我没有打算在合并前避免让子模块处于不同的版本，正如您在问题中所建议的那样。如果发生冲突，您可以选择在 def 处添加子模块来解决它。如果没有冲突，我上面提到的步骤应该可以正常工作。

Lets say I have two branches in RepoX called BranchA and BranchB. RepoX also has a submodule called SubmoduleY.

BranchA has SubmoduleY at revision 'abc', BranchB has SubmoduleY at revision 'def'.

Say I want to merge BranchA into BranchB, but I want to leave BranchB's SubmoduleY pointing to its original revision of 'def'. I see a couple ways of doing this:

Method 1:

1. Checkout BranchB.
2. Move SubmoduleY to revision 'abc' to make the actual merge painless (we don't want to do any merging at the submodule level right now).
3. Commit the new revision for SubmoduleY (we can't have it floating for the merge).
4. Merge BranchA into BranchB. Resolve any conflicts.
5. Move SubmoduleY back to revision 'def'.
6. Commit the new revision for SubmoduleY.
7. Push changes up to the main repo.

Method 2:

Same as method 1, but instead of doing step 6, rebase and get rid of the extra submodule commit from step 3.

Both seem to have annoying drawbacks:

Method 1 puts two extra commits into history.

Method 2 forgets any changes to do with submodule revisions because those commits get removed. Therefore, any merges later on will have to deal with some problems again.

Is there a better way?

解决方案

You could do a variation on your method 1, but do the commit that introduces the change to the submodule version (in your step 6) with --amend so that it changes the state of the submodule in the merge commit. In other words, this would be:

$ git checkout b
$ git merge a
Merge made by recursive.
 example.txt |    1 +
 sY          |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)
 create mode 100644 example.txt
$ cd sY
$ git checkout def
[... you get the "detached HEAD" warning ...]
$ cd ..
$ git add sY
$ git commit --amend

Note that I didn't bother trying to avoid having the submodules at different versions before merging, as you suggested in your question. If there's a conflict, you can just choose to add the submodule at def to resolve it. If there isn't a conflict, the steps I mentioned above should work fine.

这篇关于Git：合并和子模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！