Caching 与版本或日期相比，使用哈希来加速文件有什么好处？

在构建网站/应用程序时，在构建过程中向某些文件添加修订标记以阻止缓存是非常常见的。例如，文件

style.css

script.js

可能被生成脚本重命名为

58198123.style.css

87012174.script.js

通常应用程序使用MD5散列文件内容作为修订标记（例如：Ant构建脚本、Yeoman、Drupal）。我想知道在版本号、序列号或日期字符串上使用哈希有什么好处？每一个都会在一个文件中添加一些人类可读的信息，这让我感到很愉快。我确信有很好的理由用散列的方式来做，我只是没有看到任何明确的描述。

同意@Raymond Chen（对上述问题的评论）的观点，即当更改“还原”时，散列“还原”，并且可以在不提交的情况下生成散列

然而，IMHO认为，对“版本”或“日期”进行哈希运算的最重要原因是为了避免冲突，在这种情况下，多个开发人员可能正在工作，但不共享“集中式服务器”来协调修订号更新，或解决意外的时间冲突

例如：

• 如果两个开发人员希望同时进行更改，则更新“时间戳”是不明确的（但哈希不是）

• 如果两个开发人员正在工作，但不共享一个中央“版本号服务器”（例如，其中一个是“脱机”），则更新版本号是不明确的（因为两个开发人员都将声明下一个版本号），但哈希值不是不明确的

“分布式”模型是git/mercurial迁移到“散列”的原因，以消除对中央版本号服务器的需求

在您的特定情况下，如果您是唯一的开发人员，您可以争辩说您不需要这个“协调分布式更改”功能。但是，当您分叉/分支然后合并时，版本号会变得混乱/不明确

---

Subversion通过为整个存储库单调递增一个数字来处理这个问题，但是在您的用例中，您谈论的是每个文件的版本号。以前的版本控制系统（如

cvs

、

rcs

、

sccs

等）通过为每个分支/合并“添加”一个“计数器”来处理每个文件上的版本号。这些数字变得复杂，但仍然存在歧义。例如，存储库中的一个文件可以具有类似

2.3.27

的版本，另一个文件可以具有

3.2

，另一个文件可以同时具有

26

，同时，这些版本中的每一个都可以在不同分支上的文件历史记录的不同部分对单个文件“有效”（这让人困惑）。例如，

2.4.12.37.2

如果一个

MyFileA.txt

被大量分支/合并，就会变得混乱，如果两个文件意外地具有相同的版本

26

（对于一个文件，在二十个分支/合并之前已经是几年前了，而对于另一个文件，这是当前版本）。

如果文件被修改，然后更改撤消，散列将返回到上一个值，现有缓存将有效。文件版本和日期没有此属性。散列的另一个很好的特性是无需提交即可生成，这在测试本地更改时非常方便。完美的解释。我完全错过了多个开发人员的观点（这很奇怪，因为我使用git并参与了很多开源项目）。