我应该将我的网站媒体保存在我网站的存储库中吗？答案

【问题标题】：Should I keep my site media in my website's repository?我应该将我的网站媒体保存在我网站的存储库中吗？
【发布时间】：2010-10-10 20:19:17
【问题描述】：

我有一个使用 Django 用 Python 编写的简单博客应用程序。我使用 Git 对这个网站进行版本控制。该网站的主要内容是博客。博客条目存储在 SQLite 数据库中（不受版本控制，但会定期备份）；一些条目包含图像和其他媒体（如 PDF）。

我目前将此“博客媒体”与其他媒体（例如外部 JavaScript 代码和用于布局目的的图像——当然，所有这些都井井有条）一起存储在存储库中。然而，我突然想到，这并不是一个真正的好策略，原因如下：

每当我发布包含图像或 PDF 链接的新博客条目时，我都必须将图像添加到存储库，然后将新版本复制到生产服务器——这似乎需要做很多工作添加图像。将图像上传到服务器会更容易（当然还要进行本地备份）。
由于此媒体是 content 而不是 code，因此似乎没有必要将其与代码（和相关样式媒体）本身一起存储。
repo 包含大量二进制文件，这增加了 repo 的整体大小；更重要的是，
我从来没有真正编辑过这些图片，为什么要让它们受版本控制？

所以我正在考虑从 repo 中删除这些文件，并将它们复制到服务器上的目录之外，该目录包含网站的 Python 代码、模板、样式表等。

但是，我想知道：是否有“最佳实践”来处理网站存储库中的内容图像和其他媒体，而不是实际用作网站布局和功能一部分的图像等？

编辑

详细地说，我发现将网站的代码保存在 repo 和将网站的 content 保存在 repo 之间是有区别的——我觉得也许 content 应该与实际提供网站功能的代码分开存储（特别是因为内容可能会更频繁地更改，而我没有看到需要为网站本身运行所不需要的“东西”创建新的提交）。

【问题讨论】：

标签： version-control

【解决方案1】：

将它们保存在版本控制中。如果他们永远不会改变，你就不会为此付出代价。如果它们确实发生了变化，那么事实证明您毕竟需要版本控制。

【讨论】：

【解决方案2】：

最初，我会说不要将它们放在存储库中，因为它们永远不会改变，但然后考虑将您的网站移动到不同的服务器或托管服务提供商的情况。您需要一种简单的方法来部署它，除非它不受版本控制，否则很多复制/粘贴可能会出错。如果/当某事发生时，至少一切都在一个地方。

这并不是真正的答案，而是需要考虑的问题。

【讨论】：

+1，除了我在回答中提出的内容之外，还有一点需要考虑

【解决方案3】：

版本它们。为什么不？我版本的 PSD 和一切。但如果这让你畏缩，我可以理解。不过，您应该对 javascript 和样式表进行版本控制，这些东西是代码（各种）。

现在，如果通过内容，您的意思是“我为博客文章上传的图片”或“我在评论中使用的 pdf 文件”，那么我会说不——不要版本它。这种内容在数据库或其他地方都有说明。但是，标志图像、精灵和构成网站外观的东西绝对应该进行版本控制。

如果你不相信，我再给你一个敏感的理由。有一天，您会希望您可以回顾您的历史，看看您的网站在 5 年前是什么样子。如果您对外观和感觉内容进行版本控制，您将能够做到。

【讨论】：

您的回答是我问题的根源。我确实计划在 repo 中保留与布局相关的媒体（包括图像），但是“我为博客文章上传的图像”似乎不适合存储在 repo 中，因为它们不是网站功能的组成部分.

【解决方案4】：

你在两点上完全正确。

您正在对代码使用版本控制。
您正在备份实时内容数据库。

您得出了正确的结论，即“内容图像”就是这样，在您的代码的版本控制中没有任何业务。

将您的内容图像与您的数据库一起备份。您不想模糊两者之间的界限，除非您希望您的“代码”只是您自己的博客网站。

如果您想创建一个完全不同的博客怎么办。或者您的朋友都想要一个。您不会向他们提供包含您所有内容的数据库副本。对他们来说，拥有所有内容图像的副本也没有任何用处。

【讨论】：

我认为您对“源代码控制”和“版本控制”之间的区别有误。您可以写入磁盘的任何内容都可以置于“版本控制”之下。
没记错。有可能我没有按我应该的方式表达我的观点。关键是动态内容不应包含在代码库存储库中。当使用它的附加内容不是（数据库中博客的文本）时，将它放在那里是没有用的。
动态内容？我们在这里谈论的静态内容主要是图像、pdf 或其他任何被视为不经常更改的资源的内容。问题是，即使它可能是一个图像，它仍然可以更改，您可能希望在 vc 系统中控制该更改。
好的，这是动态添加到他的博客应用程序的静态内容。这是我书中的动态内容。他对代码进行版本控制，而不是单个博客条目的文本或资源。当然，他可以对他的图像进行版本控制，但这在他的代码库中没有任何意义。
这个问题有很多很好的答案！不过，Stack Overflow 坚持我将答案标记为已接受 :)，我认为这个答案最能触及我问题的核心。

【解决方案5】：

Move 版本控制系统不能很好地处理二进制文件，也就是说，如果它们不改变，就没有（一点）区别。

您只需要决定哪个更容易，将其备份到存储库和添加图像/pdf/其他内容的多步骤过程，或者为它们维护一组单独的操作（包括备份）。就我个人而言，我会将它们保留在版本控制中。如果你不改变它们，它不会伤害任何东西。为什么要担心不会造成伤害的事情？

【讨论】：

+1 同意。它们必须存储在“某处”。它们在 repo 中占用的空间并不比任何特定驱动器上的空间多（大多数情况下）。如果您使用的是颠覆，您还可以将它们标记为二进制资源 - 它会这样对待它们。

【解决方案6】：

我认为您需要问自己为什么要使用版本控制以及为什么要进行备份可能是因为您想保护自己免受文件丢失或损坏，并且在发生可怕的事情时可以回退在您的备份上。

如果您使用版本控制和单独的备份系统，您会遇到分发问题，因为您网站的最新版本位于不同的位置。如果确实出了问题，那么您需要付出多少努力才能恢复？对我来说，拥有一个带有版本控制和备份的分布式系统似乎需要大量的手工工作，而且不容易编写脚本。更重要的是，当出现问题时，你可能已经压力过大了。使恢复过程更加困难可能对您没有多大帮助。

在我看来，将静态文件置于版本控制中不会造成任何伤害。您必须将它们放在版本控制存储库或普通文件系统中的某个位置。由于您的静态文件永远不会改变它们不会随着时间的推移占用更多空间，所以有什么问题？我建议您将所有这些都置于版本控制之下，让自己轻松搞定。就我个人而言，我会定期备份我的数据库，并将此备份提交给版本控制。这样一来，您可以将所有内容集中在一个地方，并且在发生灾难时，您可以轻松地进行新的结帐/导出以恢复您的网站。

我已经建立了this 网站。它拥有大量 PDF 文件，所有内容都存储在版本控制之下。如果服务器死了，我所要做的就是一个干净的导出并重新导入数据库和站点，它再次启动并运行。

【讨论】：

【解决方案7】：

如果您正在开发一个网络项目，我建议您为您的媒体创建一个虚拟目录。例如，我们在本地工作副本 IIS 中为 /images/ /assets/ 等设置了一个虚拟目录，该目录指向客户可以访问的开发/登台服务器。

这提高了源代码控制的速度（尤其是使用像 Visual Source Safe 这样笨重的东西），如果客户在测试期间更改了某些内容，这会自动反映在我们的本地工作副本中。

【讨论】：