修复了一个糟糕的合并

Question

所以我们的团队对Git来说是新手.我们遇到了类似这样的情况,只是更糟糕的情况:开发人员进行了一次糟糕的合并,然后糟糕的合并被埋没在大约20次后续提交中,因为我们只注意到一天后的不良合并.

我们如何解决这个问题？

编辑:看起来git revert -m命令可能是诀窍,但只有一个文件,我们真的需要还原...一个严重损坏的大edmx文件.有什么方法可以将恢复限制为该文件？

Answer 1

如果只有一个损坏的文件,你可以找到一个好的提交并从那里结账:

git checkout <revision> -- path/to/file 

然后将其保存在下一次​​提交中.

Answer 2

鉴于您的编辑,我建议提取文件"预合并"的好副本以及任何所需的更改.有多种方法可以执行此操作:您可以反向应用合并带来的更改,希望任何后续更改不会发生冲突或重叠; 您可以提取一个良好的合并前版本并检查所需的任何更新; 等等.

例如,如果<revspec>是具有已知良好版本文件的提交:

$ git log <revspec>..HEAD -- path/to/file # find changes to file

(这将显示所有的承诺从到达HEAD而不是从<revspec>或其父母,感动文件;这应该包括合并本身,这显然你不希望保留,而且会显示使你可能想保留的更改提交毕竟).

$ git checkout <revspec> -- path/to/file

(这只是将旧版本提取到工作目录中,也将其写入索引,即,它已经暂存为提交).

现在,如果有修订版,您确实需要更改:

$ git show <rev> -- path/to/file | git apply
... repeat for all <rev>s, make sure they all apply;
    do manual work if needed ...
$ git add path/to/file

如果三个没有这样的修改,你不需要申请任何东西,也不需要申请add结果; 你现在准备好了git commit.

一种不同的方法,但现在你必须选择合并的哪一方引入了不好的东西.假设从第二个父级(分支合并,而不是分支合并到)中输入了不好的东西:

$ git diff <mergerev>^1 <mergerev> -- path/to/file | git apply -R

在这里,我们git diff将展示文件如何从"good"(mergerev的first-parent)变为"bad"(mergerev,从第二个parent引入更改),并将这些更改"反向应用"到工作树.

如果一切顺利,git add修复文件并提交.