撤消将文件从回购中删除的Git合并的最佳方法是什么？

因此，假设发生以下情况（并且我们都在使用SourceTree）：

1. 我们都在努力起源/发展。
2. 我去度假一个星期。
3. 我的同事在过去的几天里一直在本地工作，而没有将起源/开发重新合并到他的本地开发分支中。
4. 他尝试进行推动，并被告知必须先合并，然后再进行牵引。
5. 他遇到了冲突，阻止了自动合并后继续进行。
6. 假设Git类似于SVN，我的同事将“新”文件丢弃在他的工作副本中，然后提交合并-从起源/开发部门清除这些“新”文件。
7. 在该修订版的基础上，还需要进行为期数周的开发工作。
8. 我从假期回来，发现我缺了几天的工作。

我们对Git都是非常陌生的（这是我们使用它的第一个项目），但是我所做的修复工作是：

1. 将“ develop”重命名为“ develop_old”。
2. 将develop_old合并到新的分支“ develop_new”。
3. 将dev_new分支重置为错误合并之前的最后一次提交。
4. 从那时起，Cherry逐一挑选每个提交，以手工解决冲突。
5. 将develop_old和develop_new推到起点。

在这一点上，我希望develop_new是我们所有更改的“好”副本，并重新应用了随后的数周工作。我也假设说，“反向承诺”会做一个合并奇怪的事情，尤其是接下来的几个星期的工作价值是基于它-因为该合并包含了很多的事情，我们也有东西，我们不要想一起t。

我希望这种情况再也不会发生，但是如果再次发生，我想知道一种更轻松/更好的解决方法。当基于该合并的回购中进行了大量工作时，是否有更好的方法来撤消“不良”合并？

如果我理解正确，这是您的情况：

    ,-c--c--c--c--M--a--a--X ← develop
o--o--y--y--y--y-´

经过一些共同的历史（o），您投入并推动了工作（y）。您的同事（c）确实在其本地存储库上工作，并且合并错误（M）。之后，在M之上可能还有一些其他提交（a）。

git reset --hard develop M^2
git branch coworker M^1

现在，您的图形看起来完全像错误合并之前的样子：

    ,-c--c--c--c ← coworker
o--o--y--y--y--y ← develop

做一个很好的合并（G）：

git checkout develop
git merge coworker

导致：

    ,-c--c--c--c-、
o--o--y--y--y--y--G ← develop

现在移植其他提交：

git reset --hard X
git rebase --onto G M develop

这给出了最终结果：

    ,-c--c--c--c-、
o--o--y--y--y--y--G--a--a--X ← develop

请注意，这可能会导致更多合并冲突。同样，您只是更改了历史记录，即所有同事都应克隆/重置/重新设置为新的历史记录。

PS：当然，您应该用相应的提交ID 替换G，M并X在命令中将其替换。

您正在考虑如何修复存储库是一件好事，但是如果您的同事只删除了新文件并且没有覆盖很多更新，那么一种更简单的方法是简单地恢复已删除的文件。

我可能会先尝试仅选择原始提交（在当前标题上），然后在其中添加已丢失的代码。如果由于某种原因无法解决问题，只需将旧版本和您添加的文件一起签出，然后将其重新添加到新提交中即可。

您所描述的实际上是众所周知的Git反模式的子集，在我的一生中，我不记得它的名称-但其要旨是在Git合并期间进行任何“手动编辑”（即，编辑（实际上并不能解决任何合并冲突，但正在进行一些完全不相关的更改）被认为是极差的做法，因为它们本质上被合并本身掩盖了，并且在代码审查或调试会话中很容易被忽略。

因此，请务必向您的同事解释这是一次史诗般的失败，但在准备进行大手术之前，请考虑对创可贴打耳光。