上传图片到文件系统的版本控制

Question

阅读完在数据库中存储图像-是还是不是？之后，我认为文件系统是存储图像的正确位置。但我想知道您如何处理上传图像的备份/版本控制以及网络负载平衡在不同环境（dev/stage/prod）中的情况。

当使用数据库时，这些问题很容易处理，例如从生产环境中备份并恢复数据库到开发环境中。

您认为使用git来处理上传文件的版本控制怎么样？

生产环境：

• 将图像上传到Web服务器上的共享文件夹。
• 元数据存储在数据库中
• 图像自动添加到git存储库

开发人员：

• 检查源代码。
• 运行脚本以恢复数据库。
• 运行脚本以获取最新的图像。

我认为上述解决方案对于开发人员非常顺畅，图像将处于版本控制下，而且环境可以互相隔离。

- orjan

---

听起来是个好主意。 - grenade

使用一个与源代码完全分离的存储库并不与子模块方法相矛盾：该想法仍然是源代码存储库引用图像存储库的特定提交，但后者（图像存储库）仍然是一个“完全分离”的存储库。 - VonC

Answer 1

它可以工作，但我建议将这些图像存储在一个 git 存储库中，该存储库将成为源代码的 子模块。这样，即使图像位于其自己的存储库中，代码和图像之间仍存在强关系。此外，这样做可以避免使用大量二进制文件时出现的git gc或git prune效率较低的问题：如果图像位于其自己的存储库中，并且每个图像变化不大，则该存储库的维护相对轻松。而源代码存储库可以更加动态地发展，使用常规的 git 维护命令。

- VonC

---

感谢您对Git的反馈。我的第一个想法是使用与源代码完全分离的存储库，但子模块似乎是另一种选择。我相信运行一个试验来看看是否可能会很值得。 - orjan

Answer 2

对于我们来说，版本控制并不像分发那样重要。元数据是通过 Web 管理员添加的，图像则被放置在管理服务器上。Rsync 脚本将这些推送到用于提供生产环境图像的集群中。对于开发/测试，我们只需从生产主服务器同步回开发服务器。

Rsync 对于负载均衡和分发非常好。如果您将 git 替换为管理/主服务器，则会有一个相当不错的解决方案。

如果您可以接受备份只保留备份时文件历史记录（而不是每个版本的版本控制），那么可以根据此进行一些适应：使用 rsync 进行自动快照式备份。

- Matt

---

感谢您的反馈，我认为对我们来说，分发和备份比版本控制更重要。 - orjan