推送后重做错误的git冲突解决方案 [英] Redo bad git conflict resolution after push

问题描述

我想重新创建合并冲突，以便第二次可以正确解决它.

I want to re-create a merge conflict so I can resolve it correctly the second time round.

示例:

• 分支"A"已签出.
• 分支"B"已合并到其中.
• 通过合并解决的冲突(创建合并提交).
• 推到远程.
• 其他人合并到"A"分支并推送到远程.
• 哦，亲爱的我已经意识到我解决冲突的方法是错误的，我选择了他们而不是我的，
• 现在呢?

我本质上是想重新执行冲突解决部分.

我无法选择重新设置HEAD，因为分支已经被推送到远程了；并且在我意识到解决冲突是错误的之前，可能还有其他人对此做出了承诺.

I don't have the option of re-setting my HEAD as the branch has already been pushed to the remote; and has the possibility of other people having committed on it, before I had realised the conflict resolution was wrong.

我也想避免对分支"A"进行直接修复.

I also want to avoid making a direct fix on branch 'A'.

我想避免摘樱桃.我知道我可以执行标准还原，并选择我的提交等，但我不想这样做.

I want to avoid cherry picking. I know I can do a standard revert and cherry pick my commits etc, I don't want to do this.

那么有什么优雅的方法吗?

So is there any graceful way of doing this?

我尝试还原合并提交，然后又还原并合并分支"B"，但是不幸的是，它并没有要求我第二次解决任何冲突，标准的已经更新"消息.

I have tried reverting the merge commit then reverting the revert and merging branch 'B' back in again, but unfortunately it does not ask me to resolve any conflicts the second time round, I just get the standard 'Already up to date' message.

简单地讲，我想重新创建我的冲突，以便我第二次可以正确解决它.

Putting it simply, I want to re-create my conflict so I can resolve it correctly the second time round.

任何帮助将不胜感激.

谢谢.

推荐答案

此处有两个步骤.首先是重新创建合并和冲突.第二个是将其应用于分支的新尖端.

There's two steps here. First is recreating the merge and conflict. The second is applying it to the new tip of the branch.

你有类似的东西.

1 - 2 - 5 - 6 - 7 - 9 - 10 [A]
     \         /
      3 - 4 - 8

7是合并提交，您想重做一次并将修复应用到A之上.由于太多的工作堆积在了基础上，重新部署可能会变得凌乱.

7 is the merge commit and you want to redo that and apply the fixes on top of A. Rebasing might get messy because too much work has been piled on top.

首先，让我们重新创建合并冲突.为此，我们将再次进行.结帐6，这就是合并A的位置，然后将其与8合并.

First, let's recreate the merge conflict. To do that we'll just do it over again. Checkout 6, that's where A was when you merged, and merge it with 8.

git checkout 6
git merge 8

您必须使用git log --graph来确定实际的提交ID.现在我们有了合并冲突.可以像解决 但不要提交 那样解决它.而是将其藏起来. git stash save.这会将差异保存在名为隐藏的角落".这只是保存补丁程序的一种更正式的方式.

You'll have to use git log --graph to determine the actual commit ids. Now we have the merge conflict. Resolve it as you would but don't commit it. Instead, stash it. git stash save. This will save the diff off in a corner called "the stash". This is just a more formal way of saving patches.

现在我们已经有了解决冲突的方法，请检查A并从存储中应用修复程序.

Now that we've got the conflict resolution as it would have happened, checkout A and apply the fix from the stash.

git checkout A
git stash pop

由于A发生了更改，因此您可能会遇到新的冲突.没关系.正常解决它们并提交.

Since there's been changes to A, you may get fresh conflicts out of this. That's fine. Resolve them normally and commit.

这篇关于推送后重做错误的git冲突解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！