假设我在 RepoX 中有两个分支,分别称为 BranchA 和 BranchB。 RepoX 还有一个名为 SubmoduleY 的子模块。
BranchA 的 SubmoduleY 版本为“abc”,BranchB 的 SubmoduleY 版本为“def”。
假设我想将 BranchA merge 到 BranchB 中,但我想让 BranchB 的 SubmoduleY 指向其原始版本的“def”。我看到有几种方法可以做到这一点:
方法一:
- checkout BranchB。
- 将 SubmoduleY 移至修订版“abc”,使实际 merge 变得轻松(我们现在不想在子模块级别进行任何 merge )。
- 提交 SubmoduleY 的新修订(我们不能让它为 merge 而 float )。
- 将 BranchA merge 到 BranchB。解决任何冲突。
- 将 SubmoduleY 移回修订版“def”。
- 提交 SubmoduleY 的新修订。
- 将更改推送到主存储库。
方法二:
与方法 1 相同,但不是执行步骤 6,而是 rebase 并删除步骤 3 中的额外子模块提交。
两者似乎都有恼人的缺点:
方法 1 将两个额外的提交放入历史记录。
方法 2 会忘记任何与子模块修订有关的更改,因为这些提交已被删除。因此,以后的任何 merge 都将不得不重新处理一些问题。
有没有更好的办法?
最佳答案
您可以对您的方法 1 做一个变体,但是使用 --amend
提交将更改引入子模块版本(在您的步骤 6 中),以便它更改状态 merge 提交中的子模块。换句话说,这将是:
$ 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
请注意,正如您在问题中所建议的那样,我并没有费心尝试在 merge 之前避免子模块处于不同版本。如果有冲突,您可以选择在 def
处添加子模块来解决。如果没有冲突,我上面提到的步骤应该可以正常工作。
关于Git: merge 和子模块,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4380019/