我觉得这将是一个显而易见的答案，但我似乎无法解决。
可能发生的情况是，我提交/推送对服务器的一些更改，并且副本上的所有内容都显示良好。
然后，另一个开发人员从同一个分支（据我所知，据称看到了我的更改），进行一些修改，将它们提交到自己的本地副本，然后最后将其推回到服务器。
在执行此操作的过程中，我的更改会丢失，因为它们的推送（326C8FD0…）会导致与许多删除/添加行合并，从而将存储库重置回更旧的版本。这已经发生过几次了，即使是存储库的新副本。
下面突出显示的行（8def6e9..）是我所做的提交，假设其他开发人员进行了更改，那么下面的提交应该位于同一个分支上。在326C8FD0处发生合并，最终会错误地重置存储库，丢失以前的更改。
我是否遗漏了一些非常明显的事情来解释为什么会发生这种情况？我们都在用乌龟球。
对不起，可能是含糊不清的解释。
最佳答案
在您的示例中，有人正在合并f36908d（第一个父级；合并时的头）和8def6e9（第二个父级；可能是合并时原始分支的尖端）以生成326C8fd0。
如果合并提交（326C8FD0）缺少与其父级（f36908d和8def6e9；您说它缺少后者的部分）相关的重要内容，那么创建合并提交的任何人都可能以不适当的方式执行合并。
此人可能正在使用ours合并策略（merge or pull with-s ours/--strategy=ours），默认递归合并策略的ours选项（merge or pull with-X ours/--strategy-option=ours），或者在手动解决合并冲突时，他们可能只是做了错误的决定。ours策略完全忽略了历史上所有父母（除了第一个）所做的任何内容更改。通常可以标识这种类型的合并，因为合并提交及其第一个父级（即它们的更改）将具有相同的树（即，git diff f36908d 326c8fd0不会显示任何差异）。
合并策略选项还将忽略来自第二个父级历史记录的更改（即您的更改），但仅忽略那些与第一个父级历史记录中所做的更改（即更改）冲突的更改。在这种情况下，来自第二个父对象的一些更改可能会使其成为结果，但其他更改可能会完全删除。
另一种可能的选择是，它们只是在解决默认合并过程中产生的冲突时做出了错误的决定。
不管是哪种方式，有人都可能需要与进行合并的用户进行交谈，以准确地了解他们所做的以及为什么要进行合并，从而制定出一个策略来防止将来出现问题。
要恢复，您可以重新进行合并，然后将结果合并到当前历史提示中：
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