在基于git的CMS中，如何唯一标识git存储库中的文件？

Question

我正在开发类似于Jekyll和Hyde的简单CMS（基于Django，并不重要），但是是动态的而不是静态的。 想法是服务器具有存储库的副本，我可以将其放入其中，然后CMS将自动获取新内容。

假设我的存储库中Markdown格式的博客文章遵循以下文件命名方案：

/blog/2010/08/14/my-blog-post.md

在内部，处理后的文件将以唯一ID缓存在SQLite数据库中，以便于搜索和快速投放。

问题在于以这样一种方式构造URL，即可以将它们映射到存储库中的文件。 我看到几个选择：

/blog/2010/08/14/my-blog-post
如果我只是将URL（的一部分）映射到文件名，则重命名文件将断开指向该文件的所有链接。 内容管理员可以将符号链接保留在旧文件的位置，CMS可以将其映射到HTTP重定向，但这需要易于忘记的工作。
/blog/2010/08/14/271-my-blog-post
如果我在每个URL中都包含一个数据库ID，那么清除或重建缓存将使所有ID失效，甚至更糟。 我希望git存储库是唯一代表网站内容的内容； 其他一切都应该可以从中重建。
/blog/2010/08/14/528dc05-my-blog-post
据我所知，随着时间的推移，唯一可以唯一识别仓库中文件的是一对（文件名，SHA1）。 该文件肯定存在于该提交中，我们可以通过git日志将其跟踪到当前HEAD。
（我不会包括完整的SHA1，但足以使碰撞不太可能发生。稍后将进行数学计算。）

我的问题是双重的：

Answer 1

容易/快速？ 不确定，但我不这么认为。 Git以blob形式跟踪文件的内容。 然后将这些Blob的文件名存储在树对象中。 然后，提交指向树对象，并添加一些元数据，例如committer，datetime和父提交。

我不认为Git实际上会这样存储重命名，这只是指向相同blob的树之间的区别。

我认为您最好的办法是将/ path / to / file作为URL，并且当您在HEAD中找不到该文件时，请在历史记录中反复进行向后扫描，以查找存在该提交的位置。

如果您打算做这种存储库级别的工作，我建议您选择一份Peepcode的Git Internals副本，该副本很清楚地解释了git存储库的内部工作原理。