以下是我面临的情况:开发分支在主服务器中合并。在分支机构完成的工作很棒,但冲突的解决方案非常糟糕(使用--ours)
-x--x--x--M--z--z
/
-a--a--a
x和a中的内容很好,但问题来自M.所以,理想情况下,我想恢复合并M并再次合并,但这只能通过“恢复恢复”来完成,这不允许我改变合并的方式(如果我没错的话)。
我该怎么做?
(所有提交已经被推送和共享,所以我想避免重置)
答案 0 :(得分:1)
至少有几个选择:
如果您想撤消合并并以不同方式再次执行,那么您将转到rewrite history,这意味着SHA-1哈希为M
并且所有以下提交将更改。如果您没有办法将此信息传达给克隆存储库且可能已经获取旧提交的所有人,则可能会出现问题。
话虽如此,您可以通过执行interactive rebase来修复合并提交。
假设HEAD
上有master
:
x--x--x--M--z--z <- master, HEAD
/
a--a--a
你可以做到
git rebase -i HEAD~3 --preserve-merges
在HEAD 之前从 3提交启动rebase,这将是合并提交之前的提交。 --preserve-merges
选项可确保合并提交本身可在 TODO列表中进行修改。此时,您可以为M
标记edit
并继续修改。
如果您不想重写历史记录,最简单的解决方案是简单地进行新的提交,以纠正原始合并M
引入的任何错误:
x--x--x--M--z--z--F <- master, HEAD
/
a--a--a
其中F
是新提交,通过修复引入的问题来补偿M
。
答案 1 :(得分:0)
我认为我最终自己想出来了。
我的想法是在有问题的合并之前从主服务器创建一个新的分支,重新创建(正确)与开发分支的合并,从主服务器中提取并最终合并回主服务器。
更多细节,我创建了一个分支&#39;修复&#39;在有问题的合并之前,并在新分支中合并开发分支。然后,我可以根据需要合并两个分支。
-x--x--x--M--z--z
X
-a--a--a \
\ \
M'
然后,我挑选来自主人的提交
-x--x--x--M--z--z
X
-a--a--a \
\ \
M'--z--z
最后,我合并了&#39;修复&#39;主人的分支。这将创建另一组冲突(因为两个合并)需要修复(但几乎可以肯定地保持修改&#39;修复&#39;分支)。最后,主人处于我想要的状态。
-x--x--x--M--z--z-----N
X /
-a--a--a \ /
\ \ /
M'--z--z
至少,这在我的案例中有效。