git - Git 中基于内容的寻址有什么好处?

标签 git sha

问题:

Git 使用基于内容的文件寻址系统(即它使用 blob 和树哈希作为“文件名”)。我想知道这种寻址系统有什么好处?

我可以清楚地看到一些的好处,但这些好处很小:

  1. 如果有人更改 git 仓库中的某个文件,它将破坏所有指向它的提交。因此,您肯定会知道发生了不好的事情。但它真的那么有用吗?
  2. 对文件使用哈希将真实文件名与其内容分离,因此您可以“廉价地”重命名文件...

我觉得使用 sha 进行文件寻址的真正原因是完全不同的。谁能解释一下?

附言澄清。问题是关于为什么 Git 使用散列来寻址文件而不是它是如何这样做的。我知道一些方法,我需要知道为什么。

附言有一篇关于 Git principals 和 why Git looks so strange 的文章(因为它应该在除了核心操作系统和文本编辑器之外没有其他软件的机器上使用),但本文仍然只提到这个原因:

if you calculate sha of a file and this sha is already in the objects folder, then you know that you need not store it again, since sha depends on contents.

好吧,这就是为什么我明白了。还有其他为什么要使用内容可寻址文件系统

最佳答案

git 需要做的最常见的事情之一就是比较一个项目的两个版本。因为对象存储(提交、树和 blob)是内容可寻址的,所以这可以通过比较“文件名”来非常快速地完成。

此外,在存储内容时,很容易看出它是否是您已存储内容的副本,因此您可以避免存储重复项。

关于git - Git 中基于内容的寻址有什么好处?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/65199783/

相关文章:

coldfusion - 如何从 ColdFusion 9 中的哈希函数获取原始二进制文件?

c# - 将 C# SHA256 哈希转换为 Ruby

php - 如何使用 PHP 验证 ecdsa-with-SHA256 签名?

git - 有没有办法在检查更改时使用 git 累积提交消息?

git - 如何在不要求每个子存储库的密码的情况下使用子模块克隆 git 存储库

xml - CentOS Epel 错误

c++ - 使用 OpenSSL 库生成 "___report_rangecheckfailure"错误

git - 需要修补的子模块的 git 解决方案是什么?

Git 将主文件 merge 到分支时将整个文件标记为冲突

c# - Ruby 中的 SHA256 Base64 哈希