为什么合并后更改丢失得无影无踪？
Why are changes missing without a trace after a merge?
在处理我们的代码时，我们在 git repository:
内部遇到了问题
8 月 15 日，class“UserHelper”中的方法“CheckforLogout”仍然存在（提交：08cc360 或图中的绿色提交）。 8月26日之后，这个方法就彻底没了。
我检查了是否有删除该方法的提交，但有 none。
在阅读了类似的 之后，我开始将提交与结果一分为二，即提交 9013cf5（图中的黄色提交）是“错误的”。
造成此行为的可能原因是，我的老板进行了更改并将它们提交到存储库，而没有先拉取。由于他的存储库已经过时，因此需要进行合并。由于这次合并，我的方法被删除了。
因此“错误提交”已过时，没有我的方法。
对我来说重要的问题：
- 为什么又没有被移除的方法入口了？
- 我可以从软件方面防止这种行为吗？
我们目前正在为我们的 git 服务器使用 GitLab 12.6.4-ee。
感谢您的关注！
您显示的图片可能没有提供足够的上下文来准确说明正在发生的事情；但我们可以从这个开始：黄色提交（标记为“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
（此操作将在“分离的 HEAD”状态下进行，并且将是 throw-away 合并，只是为了重新创建发生的事情。之后您可能想要中止合并并返回到您的工作分支。)
如果确实存在影响您功能的冲突，那么最有可能的解释是未正确解决。如果是这样，这不是 git 可以解决的问题 - 手动解决冲突的要点是该工具不能自动决定什么是正确的。有时您无法让工具保护您免受犯错的人的伤害。
（解决合并冲突是一项技能。通常不难看出您应该做什么，但是例如，如果另一个分支实际上正在从代码的同一区域删除代码，那么冲突标记可能看起来您的代码只是被删除块的一部分。）
请注意，任何与您的冲突的更改都不一定在 G 中；它只是 somehwere 在 O 和 P2 之间。
如果，你重做merge的时候没有冲突，那么接下来就是看你的merge版本是否还包含你的代码；如果没有冲突，那就应该。如果没有，那么将需要更多信息来弄清楚发生了什么 - 不幸的是，我不知道在那个时候要问什么，除了实际检查回购协议（我确信这有点过于专有） .
如果重做合并 确实 包含您的代码，那么由于某种原因，原始合并的完成方式不同，这只有执行合并的人才能解释。
[1] 在这种情况下，我在提交拓扑的意义上使用了“不同的分支”。可能每个人都在 master 上工作并认为自己“在同一个分支上”，但是如果你在另一个人工作时推送，然后他们从远程拉取更新，这就像来自远程 (origin/master) 的代码与本地代码（只是 master）位于不同的分支上。
在处理我们的代码时，我们在 git repository:
内部遇到了问题
8 月 15 日，class“UserHelper”中的方法“CheckforLogout”仍然存在（提交：08cc360 或图中的绿色提交）。 8月26日之后，这个方法就彻底没了。
我检查了是否有删除该方法的提交，但有 none。
在阅读了类似的
造成此行为的可能原因是，我的老板进行了更改并将它们提交到存储库，而没有先拉取。由于他的存储库已经过时，因此需要进行合并。由于这次合并，我的方法被删除了。
因此“错误提交”已过时，没有我的方法。
对我来说重要的问题：
- 为什么又没有被移除的方法入口了？
- 我可以从软件方面防止这种行为吗？
我们目前正在为我们的 git 服务器使用 GitLab 12.6.4-ee。
感谢您的关注！
您显示的图片可能没有提供足够的上下文来准确说明正在发生的事情；但我们可以从这个开始：黄色提交（标记为“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
（此操作将在“分离的 HEAD”状态下进行，并且将是 throw-away 合并，只是为了重新创建发生的事情。之后您可能想要中止合并并返回到您的工作分支。)
如果确实存在影响您功能的冲突，那么最有可能的解释是未正确解决。如果是这样，这不是 git 可以解决的问题 - 手动解决冲突的要点是该工具不能自动决定什么是正确的。有时您无法让工具保护您免受犯错的人的伤害。
（解决合并冲突是一项技能。通常不难看出您应该做什么，但是例如，如果另一个分支实际上正在从代码的同一区域删除代码，那么冲突标记可能看起来您的代码只是被删除块的一部分。）
请注意，任何与您的冲突的更改都不一定在 G 中；它只是 somehwere 在 O 和 P2 之间。
如果，你重做merge的时候没有冲突，那么接下来就是看你的merge版本是否还包含你的代码；如果没有冲突，那就应该。如果没有，那么将需要更多信息来弄清楚发生了什么 - 不幸的是，我不知道在那个时候要问什么，除了实际检查回购协议（我确信这有点过于专有） .
如果重做合并 确实 包含您的代码，那么由于某种原因，原始合并的完成方式不同，这只有执行合并的人才能解释。
[1] 在这种情况下，我在提交拓扑的意义上使用了“不同的分支”。可能每个人都在 master 上工作并认为自己“在同一个分支上”，但是如果你在另一个人工作时推送，然后他们从远程拉取更新，这就像来自远程 (origin/master) 的代码与本地代码（只是 master）位于不同的分支上。