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

Question

我有一种感觉，这将是一个明显的答案，但我似乎无法解决这个问题。

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

然后另一个开发人员从同一个分支机构（从据我知道的那样看到我的更改）从服务器中撤出，进行一些修改，将它们提交到自己的本地副本，然后最终将其推送回服务器。 / p>

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

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

我是否遗漏了一些非常明显的原因？我们都在使用TortoiseGit。

对于可能含糊不清的解释感到抱歉。

Answer 1

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

如果合并提交（326c8fd0）缺少与其父节点相关的重要内容（f36908d和8def6e9;你说它缺少后者的部分），那么创建合并提交的人可能正在执行合并以不合适的方式。

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

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

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

Answer 2

如果你丢失了提交，请确保你们两人都没有在你的gui上使用--force或强制标志来摆脱被拒绝。看看DAG的解释。

http://progit.org/book

希望这会有所帮助。