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

Question

我对此有点疑惑......

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

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

git 现在显示的是他在分支 A 中的提交及其哈希值，以及在我的( fork 的)分支中的相同提交，将我显示为作者，以及一组不同的哈希值，与我正在做的工作混合在一起在我的分支上。

这感觉像是某种 rebase 问题(我们有时都使用 GitHubForWindows，它确实将 rebase 作为同步的一部分)，但我不知道有人向我们报告了一个问题。

任何有关造成这种情况的原因或如何解决问题的想法都将不胜感激。

Answer 1

你应该得到一些强大的工具(普通的 gitk 应该就可以了)并仔细检查匹配的(但哈希不同的)提交——在 Author 中寻找差异, Committer 和 Date 字段。还要比较父提交的哈希值，因为提交对象还记录其父提交的哈希值，因此引用不同父 SHA-1 提交名称的相同提交将不同。

您还可以详细说明您的提交与您的同行编写的提交“混合”的精确程度吗？所有这些提交是否形成线性历史或是否存在 merge 点？

前者表示使用了 rebase 。

根据目前可用的信息，我会这样做:

1. 停止使用“Github for Windows”，因为简单的解决方案往往会造成您现在面临的情况:当某些东西坏了时，您不知道它为什么坏了，也不知道如何恢复。

2. 获取“常规”Git for Windows (并且可能是 Git Extensions 如果你想要花哨的 GUI，它不会试图超越用户)。

3. 通过从中 fork 出另一个分支来保存您当前的功能分支。

4. (硬)将您的功能分支重置为同行的分支。

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

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

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

然后你和你的同事都应该阅读 merge 和 rebase 工作流，采用其中之一，然后在处理功能分支时，明智地进行 merge 和/或 rebase ，理解为什么你正在这样做，结果会发生什么。我建议您不要盲目依赖工具来做正确的事™。