如何恢复使用策略=我们的合并？

Question

我正在使用一个存储库，其中几周前执行了合并，我们刚刚发现它使用了

--strategy=ours

标志（它应该使用 --strategy-option=ours 标志），因此没有对 HEAD 应用任何更改。但是，我们需要应用这些更改。 Git 已经识别出正在合并的分支以及分支历史记录中的提交。

这种合并无法使用

git revert -m ...

恢复

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

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

合并提交

(F)

将是这种情况下的罪魁祸首。

Answer 1

我已经找到了解决这个问题的方法。这一切都在 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 –––> L–––M–––N–––F2
             \     /
topic         C–––D

要真正深入了解这一点，请阅读这封信的最后部分如何使用 --no-ff

 变基选项重新创建分支来恢复错误的合并。

Answer 2

@生命之路有一个很好的答案。有一件事是，重新设置基准的提交现在看起来像新的不同提交，这在许多情况下可能是不可取的。我想再次合并相同的提交，但是

git-merge

 阻止了这一点。然而，我一次又一次地发现，总是可以让 git 做你想做的事情。

1. 遵循生命高速公路的指示，但不要直接合并到master上：

   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 –––> L–––M–––N–––F2
                   \     /
   topic            C–––D

2. 现在树已完全按照您想要的方式设置 - 所有文件都完全显示您想要的内容。一个问题是您的合并提交的父项是原始提交的重新基副本，而不是实际的原始提交本身。解决这个问题很容易

   git-reparent

   :
   git reparent -p master -p <D> 最终结果是：

   master     A–––B–––E–––F–––G –––> 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 –––> L–––M–––N–––F2---R
             \     /                           /
topic         C–––D----------------------------

Answer 3

合并策略“无论要合并什么，都保留这里的内容”，其本质是无法逆转的。在新分支中签出合并的第一个父级，然后再次进行合并。变基——将原始合并之上的其余提交合并到此提交上。

更新：

就你而言，如果你不关心过去，你可以将 G-N 重新设置为 E，然后将 D 合并到这个新的 master 上。变基将是微不足道的，因为 F 是一个 --ours 合并。

Answer 4

我刚刚做了一个

git reset --hard commitHashBeforeMerge

然后

git push -f