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

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

|| 我觉得这将是一个显而易见的答案，但我似乎无法解决。 似乎发生的事情是我对服务器进行了一些更改，这些副本在我的副本上看起来都很好。 然后，另一名开发人员从同一分支从服务器中拉出（据我所知，据悉我所做的更改），进行了一些修改，将它们提交到自己的本地副本，然后最终将其推回服务器。 在执行此操作的某个地方，我的更改由于其推送（326c8fd0 ...）导致合并而丢失，其中包含大量删除/添加行，从而将存储库重置为更旧的版本。即使使用存储库的新副本，现在也已经发生了几次。 下面的突出显示的行（8def6e9 ..）是我所做的提交，假定其他开发人员撤消了更改，则以下提交应该在同一分支上。合并发生在326c8fd0，最终错误地重置了存储库，从而丢失了先前的更改。 我是否很清楚为什么会发生这种情况？我们都在使用TortoiseGit。 抱歉，您的解释可能含糊不清。     

解决方法

在您的示例中，某人正在合并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 希望这可以帮助。