Git：由于看似随机的合并，更改不断丢失

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

似乎发生的情况是，我向服务器提交/推送了一些更改，并且我的副本上的一切都显示正常。

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

在执行此操作的过程中，我的更改丢失了，因为它们的推送（326c8fd0 ...）导致与大量删除/添加行的合并，将存储库重置回更旧的版本。即使使用存储库的新副本，这种情况也已经发生过几次。

下面突出显示的行（8def6e9..）是我所做的提交，假设其他开发人员拉取了更改，则以下提交应该位于同一分支上。合并发生在 326c8fd0，最终错误地重置了存储库，丢失了之前的更改。

我是否遗漏了一些非常明显的事情来解释为什么会发生这种情况？我们都使用 TortoiseGit。

很抱歉可能含糊的解释。

在您的示例中，有人正在合并 f36908d（第一个父级；合并时的 HEAD）和 8def6e9（第二个父级；可能是合并时原始分支的尖端）以生成 326c8fd0。

如果合并提交 (326c8fd0) 缺少与其父级相关的重要内容（f36908d 和 8def6e9；您说它缺少后者的部分），那么创建合并提交的人可能会以不适当的方式执行合并。时尚。

此人可能正在使用ours合并策略（合并或拉取-s ours/--strategy=ours), the ours默认递归合并策略的选项（合并或拉取-X ours/--strategy-option=ours），或者他们可能只是在手动解决合并冲突时做出了错误的决定。

The ours策略完全忽略历史记录中除第一个父母之外的所有父母所做的任何内容更改。您通常可以识别这种类型的合并，因为合并提交及其第一个父级（即它们的更改）将具有相同的树（即git diff f36908d 326c8fd0不会显示任何差异）。

The ours合并策略选项还将忽略第二个父级历史记录中的更改（即您的更改），但仅忽略与第一个父级历史记录中所做的更改冲突的更改（即它们的更改）。在这种情况下，来自第二个父级的一些更改可能会进入结果，但其他更改可能会被完全删除。

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

无论哪种方式，有人可能必须与进行合并的用户交谈，以查明他们到底做了什么以及为什么这样做，以便制定策略来防止将来出现问题。

要恢复，您可以自己重做合并，并将结果合并到历史记录的当前提示中：

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