每个分支的尖端的哈希值是否足以证明整个存储库的完整性？为了便于讨论，假设您必须将整个存储库交给某人，让他们做任何他们想做的事情，并确定他们是否改变了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是我故意孤立的分支here。一切似乎都适合我。列出了我期望的所有分支，但如果每个分支提示的SHA都是我需要的，那么我不肯定。我错过了什么吗？
标签怎么样？那些被删除而没有合并成任何东西的分支呢？
正如一些评论中指出的那样，除了可能需要考虑的头部之外，可能还有其他参考文献。例如，tags和notes可能会有用，具体取决于它们对您是否重要，或者您是否对代码进行签名。对于我自己，我主要对提交内容感兴趣，这就是我接受VonC答案的原因。
答案 0 :(得分：5)
这在诚信方面似乎已经足够了
标签引用提交，因此如果提交发生更改，git fsck将检测标记与其不存在的提交之间的不一致性。
请注意，诚信与信任不同（即担保内容）
为此，“A Git Horror Story: Repository Integrity With Signed Commits”具有指导意义。
首先，它的“Commit History”部分详细介绍了SHA-1完整性背后的理论（也在“Git and Data integrity”中提出，最后总结：
尽管如此，重要的是要了解只有在无法创建 hash collision 时才能保证存储库的完整性 - 也就是说，如果攻击者能够创建相同的SHA -1使用不同数据的哈希，然后子提交仍然有效，并且存储库已成功泄露 Vulnerabilities have been known in SHA-1 since 2005允许计算哈希faster than brute force，但它们的开发并不便宜 鉴于此，虽然您的存储库目前可能是安全的，但未来将会出现一些问题，即SHA-1将被视为今天的MD5瘫痪。