为什么合并后更改丢失得无影无踪？

Question

在处理我们的代码时，我们在git repository 中遇到了一个问题：
8 月 15 日，“UserHelper”类中的“CheckforLogout”方法仍然存在（提交：08cc360 或图片中的绿色提交）。 8月26日之后，这个方法就彻底没了。

我检查了是否存在删除方法的提交，但没有。

在阅读了类似的thread 之后，我开始将提交与结果一分为二，提交 9013cf5（图片中的黄色提交）是“坏的”。

这种行为的可能原因是，我的老板进行了更改并将它们提交到存储库而没有先拉动。由于他的存储库已经过时，因此需要进行合并。由于这次合并，我的方法被删除了。

因此“错误提交”已经过时，没有我的方法。

对我来说重要的问题：

• 为什么再次被删除的方法没有条目？
• 我可以从软件方面阻止这种行为吗？

我们目前正在为我们的 git 服务器使用 GitLab 12.6.4-ee。

感谢您的考虑！

Answer 1

您展示的图片可能没有提供足够的上下文来准确说明正在发生的事情；但我们可以从这个开始：黄色提交（标记为“bisect bad”）与“绿色”提交及其之后的所有内容位于不同的分支 [1] 上，并且它的父级未显示在图片中（它在底部屏幕）。因此，结合您所解释的内容，我们可以做出一些有根据的猜测：

我们很可能正在寻找类似的东西

... O -- x -- G -- x -- P1 -- M -- ... <--(HEAD)
     \                       /
      Y -- x -- x -- x -- P2 

现在大概当您一分为二时，您将G 标记为“已知良好”，将HEAD 标记为“已知不良”。 G 的每个祖先都将被排除在搜索之外，因此 Y 将作为不符合您条件的最旧提交而被挑选出来。 （它不是 G 的祖先，但它不包含您的代码。）为了澄清这一点 - 您的代码 also 不在 O 中，但您不会想到它是 - 它还没有被添加 - 所以 bisect 没有关注 O （因为它是 G 的祖先，众所周知是好的）。

但是Y 真的很好；问题很可能出现在M。在正常合并期间，git 会查看从 O 到 P1 的所有更改——包括在 G 处添加的代码——以及从 O 到 P2 的所有更改。它将尝试在 O 之上应用所有这些更改以生成合并结果。

从O 到P2 的某些更改很可能与添加代码冲突，需要手动干预。您可以通过再次执行相同的合并操作来确认。

git checkout P1
git merge P2

（此操作将在“分离 HEAD”状态下进行，并且将是一次性合并，只是为了重新创建发生的事情。之后您可能想要中止合并并返回到您的工作分支。）

如果确实存在影响您的功能的冲突，那么最可能的解释是它被错误地解决了。如果是这样，这不是 git 可以解决的问题 - 手动解决冲突的重点是该工具无法自动决定什么是正确的。有时你无法让工具保护你免受犯错的人的伤害。

（解决合并冲突是一项技能。通常不难看出你应该做什么，但是例如，如果另一个分支实际上是从代码的同一区域删除代码，那么冲突标记可能已经看起来您的代码只是被删除块的一部分。）

请注意，与您的冲突的任何更改都不一定在G 中；它只是在O 和P2 之间somehwere。

如果，当你重做合并时，没有冲突，那么接下来就是看看你的合并版本是否还包含你的代码；如果没有冲突，那么它应该。如果不是，那么需要更多信息来弄清楚发生了什么 - 不幸的是，我不知道当时要问什么，没有实际检查回购（我敢肯定这有点太专有了） .

如果重做合并确实包含您的代码，那么由于某种原因原始合并的执行方式不同，那么只有执行合并的人才能解释。

---

[1] 在这种情况下，我在提交拓扑的意义上使用了“不同的分支”。可能每个人都在master 上工作，并认为自己“在同一个分支上”，但如果你在其他人工作的时候推送，那么他们从远程拉更新，这就像代码远程（origin/master）与本地代码（只是master）位于不同的分支上。