git - 为什么我在具有不同哈希值的两个分支中具有相同的提交

我对此有些疑惑...

我有两个分支，在两个分支中都有相同的提交系列。

真实的历史是它们是由我的同事编写的，并提交并推送到分支A上的github。在某个阶段，我将分支A与我的B分支 merge 在一起。

git现在似乎显示的是他在分支A中的提交及其哈希，在我(不同的)分支中的相同提交，向我展示了作者的身份，以及一组不同的哈希，这些哈希与我在分支上所做的工作混合在一起。

感觉像是某种基准问题，(我们有时都使用GitHubForWindows并在同步过程中将基准作为基准)，但是我不知道有问题报告给我们中的任何一个。

任何导致此问题或如何解决问题的想法都将受到赞赏。

最佳答案

您应该获得一些强大的工具(简单的gitk应该做得很好)，并仔细检查匹配(但哈希值不同)的提交-在Author，Committer和Date字段中查找差异。还要比较父提交的哈希值，因为提交对象还记录了其父提交的哈希值，因此引用不同父SHA-1提交名称的相同提交将有所不同。

另外，您能否详细说明一下您的提交与同行编写的提交“混合在一起”的精确程度如何？所有这些提交形成线性历史记录还是存在 merge 点？

前者将表明已使用了重新定基。

利用到目前为止的可用信息，我将执行此操作:

不再将“Github for Windows”用于无脑的解决方案往往会造成您现在所面临的情况:当出现问题时，您根本不知道它为什么破裂以及如何破裂。

获取“常规”的Git for Windows(如果您想要精美的GUI(它不会试图超越用户)，则可能是Git Extensions)。

通过 fork 另一个功能分支来保存当前功能分支。

(Hard-)将您的功能分支重置为对等的分支。

Cherry-pick您从保存的分支中最早的更改到最新的更改。

这可能会产生冲突(因为这些提交将被植入到它们最初创建的不同状态的代码中)。

结果，您将拥有一个没有“虚假相同”提交的分支。

然后，您和您的同龄人都应该阅读 merge 和重新编制工作流的方法，采用其中一种，然后在处理功能分支时，明智地 merge 和/或重新编制工作，了解为什么要执行此操作以及发生什么情况。我建议您不要盲目地依靠工具来做Right Thing™。