4

每个分支尖端的哈希值是否足以证明我的整个存储库的完整性？为了便于讨论，假设您必须将整个存储库提供给某人，让他们为所欲为，并确定他们是否更改了哪怕是 1 位数据。你会怎么做？

如果我要推送到上游的裸存储库，这是我需要保证的所有数据，我可以在以后验证整个存储库的完整性吗？

git ls-remote --heads origin

fcce961b46784fae13be8a30c2622ddd34d970ec        refs/heads/develop
9da7bb692a72235451706f24790a3f7a100a64e2        refs/heads/feature-netty-testing
86020c50d86691caecff4a55d3b1f2f588f6291d        refs/heads/javafx-testing
871d715e5c072b1fbfacecc986f678214fa0b585        refs/heads/master
7ed641c96d910542edeced5fc470d63b8b4734f0        refs/heads/orphan-branch

那来自我用来玩的沙盒存储库。这orphan-branch是我故意孤立的分支，如此处所述。一切对我来说似乎都是正确的。列出了我期望的所有分支，但如果每个分支提示的 SHA 都是我所需要的，我并不肯定。我错过了什么吗？

标签呢？那些没有合并到任何东西就被删除的分支呢？

更新

正如一些评论中指出的那样，除了可能需要考虑的头部之外，可能还有其他参考。例如，根据它们对您是否重要或您是否正在签署标签，可能有用tags。notes对我自己来说，我主要对提交的内容感兴趣，这就是我接受 VonC 回答的原因。

4

1 回答 1

5

就完整性而言，这似乎足够了。
标签引用提交，因此如果提交更改，agit fsck将检测标签与其不存在的提交之间的不一致。

请注意，完整性不同于信任（即为内容担保）
为此，“ Git 恐怖故事：带有签名提交的存储库完整性”具有指导意义。

首先它的“提交历史”部分详细介绍了 SHA-1 完整性背后的理论（也在“ Git 和数据完整性”中进行了介绍，并总结为：

也就是说，重要的是要了解，只有在无法创建哈希冲突时才能保证存储库的完整性——也就是说，如果攻击者能够使用不同的数据创建相同的 SHA-1 哈希，那么子提交（s ) 仍然有效，并且存储库将被成功破坏。
自 2005 年以来，SHA-1 中的漏洞就已为人所知，这些漏洞使得哈希的计算速度比蛮力更快，尽管利用这些漏洞并不便宜。
鉴于此，虽然您的存储库目前可能是安全的，但在未来某个时刻，SHA-1 将被视为与今天的 MD5 一样残缺。

于 2012-08-13T10:38:12.480 回答