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

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

--strategy=ours

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

这种类型的合并不能使用

git revert-m…

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

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

---

合并提交

（F）

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

一种说“无论合并什么，都保留在这里”的合并策略本质上是无法逆转的。签出新分支中合并的第一个父级，然后再次执行合并。Rebase——在您的原始合并之上的其他提交上，重新基础到这个提交上

更新：

---

在你的例子中，如果你不在乎过去，你可以把G-N重设到E上，然后把D合并到这个新的主数据上。因为F是一个--我们的合并，所以重基将是微不足道的。

我发现了这个问题的解决方案。这一切都在Linus写的关于恢复错误合并的信中：。 在我们的例子中，

git merge--strategy=ours主题

不是有意的。即使它是一个错误的合并，也无法还原，而且它已被长期推送，具有相同的效果，即在无法还原还原提交的情况下进行还原合并提交

解决方案是签出主题分支，从第一次提交开始运行

rebase--no ff

，然后将该分支合并回主分支

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

---

要真正深入理解这一点，请使用

--no ff

重新设置分支的基础选项阅读信函的最后一部分。

@Highway of Life有一个很好的答案。一件事是，重定基址的提交现在看起来像新的不同提交，这在许多情况下可能是不可取的。我想第二次合并相同的提交，但是

git merge

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

遵循生命之路的指示，但不要直接合并到master：

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

现在，树的设置完全符合您的要求，所有文件都能准确显示您想要的内容。一个问题是合并提交的父级是原始提交的重定基副本，而不是原始提交本身。通过以下方法很容易解决此问题：

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

快进主机到新合并提交：

git checkout master
git merge re-merged

最后，你可以用

git branch -d fixed-topic re-master

完成了！现在，您的历史记录如下所示，其中一个分支合并了两次：

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

---

可以安全地说，您不想重写历史，只需在合并到文件中的分支顶端生成一个新的提交即可？实际上，重写历史将是一个不错的选择。对于这种情况，只要实际应用了更改，就无所谓了。需要注意的是：我们正在尝试将合并更正为分支“master”，master已经分支了几十次，因此历史必须能够在合并中传播到其他分支。顺便说一句，我对我的问题进行了编辑，以便更清楚一些。-自执行此合并以来，已对主分支进行了69次提交。在这种情况下，我担心重写历史，这可能会导致团队成员存储库的潜在灾难性失败，将他们的重新基准合并回我的回购可能会很有趣。也许如果没有合适的替代方案，那么走补丁路线可能是最安全的方法？最终，重新设置基础和补丁是一样的。不过，重设基础的自动化程度要高得多。请记住，如果您必须重新启动，并且不想再次执行相同的冲突解决方案，请打开您的重新访问。我不知道

reparent

选项是第三方函数。接缝是一个非常好的解决方案，但我正在寻找更简单的解决方案。

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

git checkout master
git merge re-merged

git branch -d fixed-topic re-master

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