问题描述
在编写代码时，我们在git repository内部遇到了一个问题：
8月15日，类“ UserHelper”中的方法“ Checkforlogout”仍然存在（提交：08cc360或图片中的绿色提交）。 8月26日之后，这种方法完全消失了。
在阅读了类似的thread之后，我开始将提交一分为二，结果是9013cf5提交（图中的黄色提交）是“错误的”。
此行为的可能原因是，我的老板进行了更改并将其提交到存储库而没有先拉。由于他的存储库已过时，因此需要进行合并。合并的结果是，我的方法被删除了。
对我来说重要的问题：
我们当前正在将GitLab 12.6.4-ee用于git服务器。
谢谢您的考虑！
解决方法
您所显示的图片可能没有足够的上下文来准确说明正在发生的事情；但是我们可以从这开始：黄色提交（标记为“ bisect bad”）与“绿色”提交及其后的所有内容都在不同的分支[1]上，并且其父级未显示在图片中（位于底部）屏幕上的）。因此，结合您的解释，我们可以做出一些有根据的猜测：
很可能我们正在寻找类似的东西
... O -- x -- G -- x -- P1 -- M -- ... <--(HEAD)
\ /
Y -- x -- x -- x -- P2
现在大概是一分为二时，您将G标记为“已知好”，并将HEAD标记为“已知坏”。 G的每个祖先都会被排除在搜索范围之外，因此Y会被挑出来，因为最古老的提交不符合您的条件。 （它不是G的祖先，但其中不包含您的代码。）为澄清这一点-您的代码也不在O中，但您不会没想到它会被添加-尚未被添加-因此bisect不会关注O（因为它是G的祖先，这是众所周知的）。>
但实际上Y很好；该问题最有可能在M。在正常合并期间，git会查看从O到P1的所有更改-包括在G处添加的代码-以及从O到P2的所有更改。 O。它将尝试将所有这些更改应用于O之上以产生合并结果。
从P2到git checkout P1
git merge P2
的某些更改很可能与添加代码冲突，需要手动干预。您可以通过再次执行相同的合并操作来确认。
G（此操作将在“分离的HEAD”状态下进行，并且将是一次即弃的合并，只是为了重新创建发生的事情。之后，您可能希望中止合并并返回到工作分支。）
如果确实存在影响您的功能的冲突，那么最可能的解释是它没有得到正确解决。如果是这样，这不是git可以解决的问题-手动解决冲突的目的是该工具无法自动确定正确的方法。有时候，您无法使该工具保护您免于犯错的人。
（解决合并冲突是一项技能。通常很难看到您应该执行的操作，但是例如，如果另一个分支实际上正在从该代码的同一区域删除代码，则冲突标记可以看起来您的代码只是被删除的代码块的一部分。）
请注意，与您冲突的任何更改不一定都在O中；只是在P2和master之间是。
如果重做合并时没有冲突，那么下一步就是查看您的合并版本是否仍然包含您的代码；如果没有冲突，那就应该。如果不是这样，那么将需要更多信息来确定正在发生的事情-不幸的是，我不知道当时要问什么，因为实际上没有检查回购（我确定这对它来说太专有了）
如果重做合并确实包含您的代码，则由于某种原因原始合并的执行方式有所不同，只有执行合并的人才能解释。
[1]在这种情况下，在提交拓扑的意义上，我使用了“不同的分支”。可能是每个人都在origin/master上工作，并认为自己是“在同一分支上”，但是如果您在另一个人正在工作的同时进行推送，则他们从远程拉动更新，就像来自远程（master）的代码位于与本地代码（仅{{1}}）不同的分支上。