Question

好的，所以我搞砸了！我正在使用具有以下结构的仓库

                master
                  |
                  v
A--B--C--D--E--F--G
       \
        \
         H--I
            ^
            |
         feature

我正在feature分支上工作，一旦完成，我就合并到了master。这导致合并冲突，我必须手动修复...我认为我做得正确。然而，今天，我的同事告诉我，我已经破坏了他们在F中开发的东西。这些破碎的部分与我添加的内容无关 - 显然在解决冲突时我删除了一堆东西。

我如何“恢复”回购，以便在保存我的同时恢复他们的变化？更糟糕的是，我已经删除了本地仓库中的feature分支，并且它没有被推送到原点。这就是回购现在的样子

                   master
                     |
                     v
A--B--C--D--E--F--G--J

我试过了

git reset --hard HEAD~
git merge origin/master --no-ff

希望能让我手动编辑合并的文件，但它总是会自动提取最新的...

Answer 1

不用担心。没有什么重要的损失，这是git。

如果合并，则应该进行合并提交（具有两个父项的提交）。你确定历史是怎样的吗？使用git log --graph查看合并的结构。

由于您已经将合并发布到公共存储库并且其他开发人员已经将其发布，因此我不建议使用硬重置和重新绑定。

因此，您应该找到合并提交并执行git revert <sha1ofmerge> --mainline 1 --no-commit，它将修改您的本地文件以撤消您通过合并所做的所有更改。然后查看更改，执行git checkout <files>以保留您想要保留的更改，只留下您需要做的更改，让其他开发人员更快乐。只需git commit。

进行合并提交后，您可以通过git branch feature <sha1ofmerge>^2恢复分支，此处“^ 2”表示第二个父级，即将功能合并到主服务器时。

Answer 2

您可以执行git cherry-pick <SHA-F>并重新应用该提交中的更改。

如果受影响的文件跨多个提交，您也可以

git checkout <SHA> -- <filename>

然后，您可以创建一个修复所有已损坏文件的提交。

由于您已推送更改，因此重新合并不是一个好选择。因为你想避免重写推送历史。

在git中修复错误的冲突解决方案

2 个答案: