11

我正在使用几周前执行合并的存储库，我们刚刚发现使用了该--strategy=ours标志（它应该使用 --strategy-option=ours 标志），因此没有对 HEAD 应用任何更改。但是，我们需要应用更改。Git 已经将分支识别为已合并，并且分支历史记录中的提交。

这种合并无法使用git revert -m ...

恢复和/或重新应用合并以更改文件的正确方法是什么？

master  A - B - E - F - G ---> L - M - N
             \     /
topic         C - D

在这种情况下，合并提交(F)将是罪魁祸首。

4

3 回答 3

9

我已经找到了解决这个问题的方法。Linus 写的关于恢复错误合并的信中的全部内容：如何恢复错误合并。在git merge --strategy=ours topic我们的情况下不是故意的。即使它是一个错误的合并，它也不能被恢复，并且已经被推送了很长时间，具有恢复合并提交但无法恢复恢复提交的相同效果。

解决方案是检查主题分支，rebase --no-ff从第一次提交运行，然后将该分支合并回主分支。

git checkout topic
git rebase -i --no-ff <C>
git checkout master
git merge topic

这产生了以下效果：

fixed–topic   C'–––D'––––––––––––––––––––-
             /                            \
master  A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2
             \     /
topic         C–––D

要真正深入了解这一点，请阅读如何使用rebase 选项重新创建分支来恢复错误合并这封信的最后一部分。--no-ff

于 2013-01-09T06:10:41.890 回答
4

@Highway of Life 有一个很好的答案。一件事是重新定位的提交现在看起来像新的不同提交，这在许多情况下可能是不可取的。我想再次合并相同的提交，但git-merge阻止了这一点。但是，我一次又一次地发现，总是可以让 git 做你想做的事。

  1. 遵循生命之路的指示，但不要直接合并到主人：

    git checkout -b fixed-topic <D>
git rebase -i --no-ff <B>
git checkout -b re-merged master
git merge fixed-topic

    这导致：

    re-merged               ––––––––––––––––––––------R
                       /                         /
fixed–topic      C'–––D'                        /
                /                              /
master     A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2
                \     /
topic            C–––D

  2. 现在，树已完全按照您的需要设置——所有文件都准确显示了您想要的内容。一个问题是您的合并提交的父母是原始提交的重新基础副本，而不是实际上是原始提交本身。很容易解决这个问题git-reparent：

    git reparent -p master -p <D>

    这最终得到：

    master     A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2
                \     /                        \
topic            C–––D                          \
                      \                          \
re-merged              ---------------------------R

    需要注意的重要一点是，自上一步以来，R 的内容没有改变——只有父母。

  3. 将 master 快进到新的合并提交：

    git checkout master
git merge re-merged

  4. 最后你可以清理

    git branch -d fixed-topic re-master

完毕！现在你的历史看起来像这样，一个分支合并了两次：

master  A–––B–––E–––F–––G –––&gt; L–––M–––N–––F2---R
             \     /                           /
topic         C–––D----------------------------
于 2016-05-13T20:50:17.207 回答
0

从本质上说“无论你要合并什么，都保留你所拥有的”的合并策略是不可逆转的。在新分支中签出合并的第一个父级，然后再次进行合并。Rebase --onto 您在原始合并之上的其余提交。

更新：

在您的情况下，如果您不关心过去，您可以将 GN 重新定位到 E 上，然后将 D 合并到这个新的 master 上。rebase 将是微不足道的，因为 F 是 --ours 合并。

于 2013-01-09T03:45:09.430 回答