我对这个问题非常好奇。提交ID不能随机生成，因为它们需要是唯一的。虽然它们看起来像是随机的，但我想知道，为什么它们不只是连续的数字呢？我的意思是，它们只需要在存储库中是唯一的，对吗？或者我理解错了？
谢谢！
谢谢！
提交ID从哪里来？
6
- Dunno
2
如果分配了这个任务，你会如何在一个分布式版本控制系统中获得唯一的连续数字？ - Álvaro González
@doh，没错。不过这让我对 id 是如何工作更加好奇了。 - Dunno
3个回答
7
Git提交ID是SHA-1哈希值
在像Git这样的分布式版本控制系统中，修订号必须在所有系统中保持一致。由于Git历史记录是一个有向无环图而不是线性系列，因此提交和对象使用SHA-1哈希进行跨系统的明确标识。
Git中的提交ID并非随机生成。实际上，它们是提交对象的SHA-1哈希值，其中包括树和对象的清单。有关详细信息，请参见Git内部结构。最终结果是任何给定对象哈希都是确定性的：相同的对象将导致相同的哈希，无论它如何到达当前状态。
- Todd A. Jacobs
4
由于Git是分布式的，因此没有一个“地面真相”存储库可以决定哪个提交将具有什么ID。此外，存储库无法通信哪些ID已被使用或未被使用。因此，每个Git安装都应确保尽量减少发生冲突的风险（即两个提交具有相同的ID）。
为了实现这一点，Git使用一种称为SHA1的哈希算法来计算提交ID。每个提交ID由160位数据组成，意味着您可以拥有2^160个可能的组合（约为50个零的1）。
使用哈希函数不能保证唯一性，但最小化了碰撞的概率，因为哈希算法专门设计用于确保这一点。
另一方面，SVN具有中央存储库，因此可以使用连续的整数编号。
Git本身没有处理冲突的方法：如果您拉取一组具有一个或多个冲突的提交，则Git将简单地忽略冲突的提交；保留原始提交不变。
此外：使用哈希算法不仅解决了提交 ID 的问题，还是一项安全措施：由于计算哈希时使用了提交的所有数据（差异、作者、日期和前一个提交的 SHA1），因此在没有改变自那时起每个哈希的情况下无法更改补丁。
为了实现这一点，Git使用一种称为SHA1的哈希算法来计算提交ID。每个提交ID由160位数据组成，意味着您可以拥有2^160个可能的组合（约为50个零的1）。
使用哈希函数不能保证唯一性，但最小化了碰撞的概率，因为哈希算法专门设计用于确保这一点。
另一方面，SVN具有中央存储库，因此可以使用连续的整数编号。
Git本身没有处理冲突的方法：如果您拉取一组具有一个或多个冲突的提交，则Git将简单地忽略冲突的提交；保留原始提交不变。
此外：使用哈希算法不仅解决了提交 ID 的问题，还是一项安全措施：由于计算哈希时使用了提交的所有数据（差异、作者、日期和前一个提交的 SHA1），因此在没有改变自那时起每个哈希的情况下无法更改补丁。
- Nils Werner
2
它们在远程、断开的存储库中也需要是唯一的，因此它们不能只是递增的数字。
实际上，它们是提交信息的SHA1哈希值。作为其内容的加密哈希值也很有价值，因为它意味着内容是经过加密验证的。Git在整个过程中使用哈希来确保存储库抵抗篡改。
理论上可能会出现哈希碰撞，但是加密哈希被设计成难以故意制造碰撞，并且计算机自行燃烧的概率比碰撞发生的概率更高。
- bames53
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接