Git 提交ID来自哪里？

我只是对这个很好奇。提交ID不能随机化，因为它们必须是唯一的。但它们似乎是随机的，这让我想知道，为什么它们不是连续的数字呢？我的意思是，它们只需要在存储库中是唯一的，对吗？还是我错了

谢谢

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

---

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

由于Git是分布式的，因此从来没有一个“基本事实”存储库可以决定什么提交将具有什么id。此外，存储库无法通信使用什么id。因此，每个Git安装都应该确保将发生冲突的风险降至最低（两个提交具有相同的id）

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

使用散列函数并不能保证唯一性，但可以最大限度地降低冲突的概率，因为散列算法是专门为确保唯一性而设计的

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

Git本身没有处理冲突的方法：如果您使用一个或多个冲突拉取一组提交，Git将忽略冲突提交；保留原来的一个

---

另外：使用散列算法不仅解决了提交ID的问题，而且也是一种安全措施：因为提交的所有数据（前一次提交的diff、author、date和SHA1）用于计算散列。此后，如果不更改每个散列，就不可能更改修补程序，因为它们在远程、断开连接的存储库中也必须是唯一的，所以它们不能只是一个递增的数字

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

---

从理论上讲，可能会发生哈希冲突，但加密哈希的设计使其难以故意进行，而且计算机更可能自发地触发信息火焰，而不是偶然发生冲突。

如果分配了任务，在分布式版本控制系统中，如何获得唯一的连续数字？@lvaroG.Vicario-doh，对。不过，这让我对ID是如何计算的更感好奇。