提交ID来自哪里？

Question

我真的很好奇这个。提交ID不能随机化，因为它们必须是唯一的。但它们似乎是随机的，它让我感到疑惑，为什么它们不是连续的数字？我的意思是，他们只需要在存储库中是唯一的，对吧？或者我在这里错了吗？

谢谢！

Answer 1

Git Commit ID是SHA-1哈希

在像Git这样的分布式版本控制系统中，修订号必须在所有系统中保持一致。因为Git历史是一个有向无环图而不是线性系列，所以提交和对象使用SHA-1哈希来跨系统进行明确的识别。

提交ID在Git中不是随机的。它们实际上是提交对象的SHA-1哈希值，其中包括树和对象的清单。有关其他详细信息，请参阅Git Internals。最终结果是任何给定的对象散列都是确定性的：无论它如何到达当前状态，相同的对象都将产生相同的散列。

Answer 2

自从Git发布以来，从来没有一个真正的基础事实。存储库，可以决定什么提交将具有什么ID。此外，存储库无法传达所采用的ID。因此，每个Git安装都应该确保最小化发生冲突的风险（两个具有相同id的提交）。

为了实现这一点，Git使用名为SHA1的散列算法来计算提交ID。每个提交ID由160位数据组成，这意味着您可以有2 ^ 160种可能的组合（大约1个，包含50个零）。

使用散列函数并不能保证唯一性，但最大限度地减少了碰撞的可能性，因为散列算法是专门为确保这一点而设计的。

另一方面，SVN有一个中央存储库，因此可以使用连续的整数。

Git本身没有处理冲突的方法：如果你用一个或多个冲突提取一组提交，Git将简单地忽略冲突提交;留下原来的。

另外：使用散列算法不仅解决了提交ID的问题，而且也是一种安全措施：因为提交的所有数据（前一次提交的diff，author，date和SHA1）都用于计算哈希后不可能更改补丁而不必更改从那时起的每一个哈希

Answer 3

它们也需要在远程的，断开连接的存储库中是唯一的，因此它们不能只是递增的数字。

实际上它们是提交信息的SHA1哈希值。作为其内容的加密哈希值也很有价值，因为它意味着内容可以加密验证。 Git始终使用散列来确保存储库能够抵御篡改。

理论上可能会发生哈希冲突，但加密哈希的设计使其难以刻意进行，并且您的计算机更有可能自发地爆发信息火焰，而不是偶然发生碰撞。