我正在开发一个简单的CMS（基于Django，不重要），类似于Jekyll和Hyde，但是动态而不是静态。这个想法是服务器有一个存储库的副本，我可以把东西推进去，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，但只是足以使碰撞变得不太可能。稍后会做数学。）
我的问题有两个：
git中有一种简单快捷的方法可以通过重命名到当前HEAD中的相应文件名来跟踪（文件名，SHA1）对吗？
有没有更好的方法来实现我的目标：不破坏现有网址，但仍允许重命名和缓存重建？
答案 0 :(得分：0)
易/快？不确定，但我不这么认为。 Git将文件的内容跟踪为blob。然后将这些blob的文件名存储在树对象中。然后，提交指向树对象，并添加一些元数据，如提交者，日期时间和父提交。
我不认为Git实际上存储了重命名，它只是指向相同blob的树之间的区别。
我认为您可以做的最好的事情是将/ path / to / file作为URL，当您在HEAD中找不到该文件时，在历史记录中向后迭代扫描以查找有一个的提交。< / p>
如果你要做这种存储库级别的东西，我建议你拿一份Peepcode的Git Internals副本，这很清楚地解释了git存储库的内部工作原理。