为什么github会显示两次相同的提交?

两次都不一样。这是两种不同的承诺。

犯罪人的身份 是 它的哈希ID。您列出的两个哈希ID是:

• 5191cdba6da69bceea29c9c0231f2b17dffda620 .

  此提交有一个父提交, 389975b56cf4e5db190c1ed67fe7dab0363cb62f .

• e41b0c40501ea8906fcbdcc7d37ff6ef0cd5cf02 .

  此提交有两个父提交。第一个是 8aa78399c3f9650ae9ac7db0f0fc520e11f3be6a ,第二个是 5191CDBA6DA69BCEEA29C9C0231F2B17DFFDA620 即,您询问的第二个提交的第二个父级是您询问的第一个提交。

也就是说, choroba commented ,其中第一个是进行了一些更改的提交,第二个是存储库的作者用于 结合 第一次提交到它们的提交集合中。

Git中的每个提交都有一个哈希ID,每个提交的哈希ID都是唯一的。 ^一 这就是为什么这些东西这么长这么丑:git需要 保证 与过去十年中的每一次提交(见脚注1)相比,这些散列ID现在不仅是唯一的,而且对于每一次提交 到 在下一个 一万 年(同样,见脚注1)。注意,哈希ID是通过对 提交中包含的数据 ,以便它不仅唯一地标识提交,还充当检查以确保没有人破坏内容:甚至更改一位数据 在内部 提交会产生一个全新的、不同的哈希ID。

因为散列ID又大又丑,人们通常不会直接使用它们。我们使用分支名称之类的东西 一 hash id,但是hash id会进化,所以它总是意味着 分支上的最新提交 或标记名。标记名记录一个散列ID,至少要更改它们记录的散列ID(即,只有在管理标记的人是恶意的或反复无常的情况下才会更改)。

给定包含其父提交或提交的哈希ID的提交,Git可以找到父级。这些父对象还包含 他们的 父母,所以Git可以找到祖父母。那些祖父母包含散列ID,所以Git可以找到更多的祖先。这意味着给定单个提交哈希ID,Git可以找到 那次犯罪的整个祖先 ,返回到时间的开始(好吧,提交链的时间)。因此,如果给git一个提交散列id列表 存储库中的每个分支和标记 ,Git可以找到 全部的 通过遍历这些父链,在存储库中提交。这是存储库的全部内容,除了诸如分支重新登录之类的辅助数据(它们是一个存储库的私有数据,不是跨克隆传输的)。

^一 更准确地说,这种唯一性要求只有在将要混合的存储库中才是正确的。也就是说,一些特定的哈希ID可以用于两个不同的提交,但是 只有当您不想将这两个提交放在一个存储库中时。 预测哪个提交将进入哪个存储库太难了:向hash id中放入更多的位要简单得多。

git目前使用的sha-1散列使用160位,这一点慢慢被证明是不够的, ^二 所以git人员有一个迁移计划,可以将其增加到256位。这会使“每次提交一个惟一的散列ID”的概念稍微混乱一点:相反,会有一个惟一的散列ID,使用旧样式或新样式。如果是新样式,提交将有第二个旧样式hash id,用于兼容性,但仅用于在缺少新样式hash id的紧急情况下(即与不理解新样式id的git交谈时)标识提交。

^二 不足之处并不是因为没有足够的位来唯一地对宇宙中的每个原子进行编号,而是因为通过在问题上抛出足够的计算能力,坏的参与者可以产生蓄意的散列冲突。