应用错误收集

那不是两次相同的提交。那是两个不同的提交。

提交的身份是其哈希ID。您列出的两个哈希ID是：

5191cdba6da69bceea29c9c0231f2b17dffda620。

此提交有一个父提交389975b56cf4e5db190c1ed67fe7dab0363cb62f。
e41b0c40501ea8906fcbdcc7d37ff6ef0cd5cf02。

此提交有两个父提交。第一个是8aa78399c3f9650ae9ac7db0f0fc520e11f3be6a，第二个是5191cdba6da69bceea29c9c0231f2b17dffda620，也就是说，您要求的第二个提交的第二个父级是您要求的第一个提交。

也就是说，像choroba commented一样，第一个是进行了一些更改的提交，第二个是存储库的作者用来 combine 的合并提交。提交到他们的提交集合中。

Git中的每个提交都具有这些哈希ID之一，并且每个提交的哈希ID都是唯一的。¹这就是为什么这些事情是如此之长又丑陋的原因：Git需要保证与过去十年中所做的每次提交（参见脚注1）相比，这些哈希ID不仅现在是唯一的，而且还针对下一次进行的每次提交一万多年（再次参见脚注1）。请注意，哈希ID是通过对提交中包含的数据进行加密校验和计算得出的，因此，它不仅可以唯一地标识提交，还可以用作检查以确保没有人拥有毒害了内容：即使在内更改一点数据，提交也会导致完全不同的哈希ID。

由于哈希ID大而丑陋，因此人们通常不直接使用它们。我们使用分支名称之类的东西（记录一个哈希ID，但是哈希ID不断变化，因此它总是表示分支上的最新提交）或标记名称。标记名称记录了一个哈希ID，并且（至少出于意图）永远不会更改其记录的哈希ID（即，只有在管理标记的人是恶意或反复无常的情况下，它们才会更改）。

给出一个包含其父提交或多个提交的哈希ID的提交，Git可以找到父提交。这些父母还包含其父母的哈希ID，因此Git可以找到祖父母。这些祖父母包含哈希ID，因此Git可以找到更多祖先。这意味着，给定单个提交哈希ID，Git可以找到该提交的整个祖先，可以追溯到时间的开始（当然，该时间为该提交链）。因此，如果您为Git提供了存储库中每个分支和标签的提交哈希ID的列表，Git可以遍历这些父目录，从而找到该存储库中的所有提交链。这就是存储库的全部内容，除了诸如分支引用日志之类的辅助数据（这些数据对一个存储库是私有的，没有跨克隆传输）。

¹更准确地说，此唯一性要求仅在将要混合的存储库中才成立。也就是说，某些特定的哈希ID可以重新用于两个不同的提交，但是仅当您不想将这两个提交放到一个存储库中时。预测哪些提交将进入哪个存储库太难了：将更多的比特放入哈希ID中要简单得多。

Git目前使用的SHA-1散列使用160位，但事实证明这是不够的，²，因此Git员工制定了将其增加到256位的迁移计划。这将有点混乱“每次提交一个唯一的哈希ID”的概念：相反，将使用旧样式或新样式只有一个唯一的哈希ID。如果是新样式，则提交将具有第二个旧式哈希ID，以实现兼容性，但仅用于在新样式丢失的紧急情况下（即与之交谈时）识别提交。不了解新型ID的Git。

²不足之处不是因为没有足够的位数来唯一地编号宇宙中的每个原子，而是因为通过在问题上投入足够的计算能力，不良参与者可以生成故意的哈希值碰撞。

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

1 个答案: