我的观点是，应该有可能获得重复的 git 哈希，因为哈希代码是唯一性的压缩表示，因此会有一些步骤序列产生相同的哈希代码。更重要的是，应该有一系列步骤，其中提交不同的更改但产生相同的哈希码。
例如，在同一台计算机上克隆同一存储库两次，在不同的存储库中进行几乎相同的更改（保存一个字节或位）并提交。即使在提交中使用了目录名称或时间戳，仍然应该可以获得它（尽管很少见）。例如，两个不同的人在两台不同的机器上同时进行提交。
我的问题有两个方面。这是怎么发生的以及 Git 将如何处理它。
或者更明确地说，git 如何确保您在推送之前是最新的。是否有可能一个人先推送，然后另一个人尝试推送（这两个更改都基于相同的父提交），并且 Git 看到哈希代码与远程和本地历史记录匹配，决定您可以继续，允许您推但你刚刚丢失了其中一项更改？在这种情况下，我认为它更像是以下内容：
回购1
a->b->c1
回购2
a->b->c1'->c2
假设 c1,c1',c2 都在两个存储库克隆到 b 之后发生，
现在repo1推送，没有问题
现在 repo2 尝试推送 c1' 和 c2 并且 git 确定 c1' = c1 但实际上它们不同，git 将 c2 推送到 c1 之上以获得
a->b->c1->c2
我们丢失了 c1' 中所做的更改
这可能吗？它怎么会发生以及 git 会做什么？
关于您的问题中与重复哈希相关的部分：
Git 完全依赖于生成的哈希值的唯一性，据我所知，没有任何保护措施来处理产生相同哈希值的不同数据 blob。然而，发生哈希冲突的可能性非常小，实际上可以忽略不计。如果你还担心的话本节来自 Pro Git http://git-scm.com/book/cs/ch6-1.html#A-SHORT-NOTE-ABOUT-SHA-1可以让你安心：
更有可能的是，你的编程团队的每个成员都会在同一个晚上在不相关的事件中被狼袭击并杀死。
至于你问题的第二部分（发生了什么）：
如果您碰巧提交了一个与存储库中的前一个对象散列到相同 SHA-1 值的对象，Git 将看到前一个对象已存在于您的 Git 数据库中，并假设它已经被写入。如果您尝试在某个时刻再次检查该对象，您将始终获得第一个对象的数据。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
