Git:由于看似随机的 merge ，更改不断丢失

Question

我觉得这将是一个显而易见的答案，但我似乎无法解决。

似乎发生的事情是我向服务器提交/推送了一些更改，并且我的副本上的一切看起来都很好。

然后另一个开发人员从同一分支的服务器中 pull (据我所知，据称看到了我的更改)，进行了一些修改，将它们提交到他们自己的本地副本，然后最终将其推送回服务器。

在执行此操作的某个地方，我的更改丢失了，因为它们的推送 (326c8fd0...) 导致 merge ，其中包含大量删除/添加行，将存储库重置回更旧的修订版。即使使用存储库的新副本，这种情况现在也发生过几次。

下面突出显示的行 (8def6e9..) 是我所做的提交，如果其他开发人员撤消了更改，则以下提交应该在同一分支上。 merge 发生在 326c8fd0，最终错误地重置了存储库，丢失了之前的更改。

关于为什么会发生这种情况，我是否遗漏了一些非常明显的东西？我们都在使用 TortoiseGit。

对于可能含糊的解释，我们深表歉意。

Answer 1

在您的示例中，某人正在 merge f36908d(第一个父节点； merge 时它们的 HEAD)和 8def6e9(第二个父节点；可能是 merge 时原始分支的尖端)以生成 326c8fd0。

如果 merge 提交 (326c8fd0) 缺少关于其父项(f36908d 和 8def6e9；您说它缺少后者的部分)的重要内容，那么创建 merge 提交的人可能正在执行 merge 以不恰当的方式。

此人可能正在使用ours merge 策略(merge or pull with -s ours/--strategy=ours)， ours 选项到默认的递归 merge 策略(使用 -X ours/--strategy-option=ours merge 或 pull )，或者它们可能只是在手动解决 merge 冲突时做出错误的决定。

ours 策略完全忽略历史上所有 parent 所做的任何内容更改，但第一个除外。您通常可以识别这种类型的 merge ，因为 merge 提交及其第一个父级(即它们的更改)将具有相同的树(即 git diff f36908d 326c8fd0 不会显示任何差异)。

ours merge 策略选项也将忽略第二个父项历史记录中的更改(即您的更改)，但只会忽略那些与第一个父项历史记录中所做的更改冲突的更改(即他们的变化)。在这种情况下，来自第二个父项的一些更改可能会进入结果，但其他更改可能会被完全删除。

另一种可能的选择是，他们只是在解决默认 merge 期间产生的冲突时做出错误的决定。

无论哪种方式，都可能需要有人与执行 merge 的用户交谈，以查明他们究竟做了什么，以及他们为什么这样做，以便可以制定政策来防止将来出现问题。

---

要恢复，您可以自己重做 merge ，他们将结果 merge 到历史记录的当前提示中:

git checkout -b remerge f36908d
git merge 8def6e9
# resolve conflicts and commit
git checkout develop
git merge remerge
# maybe resolve more conflicts

# eventually: git branch -d remerge

或者，如果您愿意重写历史:

git checkout -b remerge f36908d
git merge 8def6e9
# resolve conflicts and commit
git rebase --onto remerge 326c8fd0 develop
# maybe more conflicts to resolve at each rebased commit