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

在您的示例中，某人正在合并f36908d（第一父级；合并时的HEAD）和8def6e9（第二父级；可能是合并时原始分支的尖端），以生成326c8fd0。 如果合并提交（326c8fd0）丢失了相对于其父级（f36908d和8def6e9；您说丢失的是后者）的重要内容，那么创建合并提交的人可能会在不合适的情况下执行合并时尚。 此人可能正在使用

ours

合并策略（与

-s ours

/

--strategy=ours

合并或提取），默认递归合并策略的

ours

选项（与

-X ours

/

--strategy-option=ours

合并或提取），或者他们在手动解决合并冲突。 “ 0”策略完全忽略了除父母之外的所有父母在历史记录中所做的任何内容更改。您通常可以识别这种类型的合并，因为合并提交及其第一父级（即它们的更改）将具有相同的树（即

git diff f36908d 326c8fd0

不会显示差异）。 ``0''合并策略选项还将忽略第二个父级的历史记录中的更改（即您的更改），但仅忽略那些与第一个父级的历史记录中的更改冲突（即它们的更改）的更改。在这种情况下，来自第二个父级的某些更改可能会影响到结果，但其他更改可能会完全删除。 另一种可能的选择是，他们在解决默认合并期间生成的冲突时只是做出了错误的决定。 无论哪种方式，都可能需要有人与进行合并的用户进行交谈，以准确了解他们的所作所为以及执行此操作的原因，以便可以制定政策来防止将来出现此问题。 为了恢复，您可以自己重做合并，然后他们将结果合并到历史记录的当前提示中：

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

    

如果您丢失了提交，请确保您都没有在GUI上使用--force或force标志来摆脱被拒绝的情况。看一下DAG的解释。 http://progit.org/book 希望这可以帮助。