图像应该存储在git存储库中吗？

对于使用Git和Github作为版本控制的分布式团队，图像也应该存储在git存储库中吗？

在大多数情况下，图像不会改变。包含它们的文件夹只会随着添加图像的大小而增加。令人担忧的是，随着时间的推移，图像文件夹可能会通过合并大图像或仅合并其中的许多图像而变得很大。

这是最佳做法吗？还有什么其他方法可以共享分布式团队可以轻松访问的项目中所需的二进制文件？

您的图片是原始作品，还是可以从其他地方恢复（保证？）？他们需要运送从源头构建的软件单元吗？如果它们是原始的，则需要备份。将它们放在版本控制中，如果它们永远不变，则空间损失与备份相同，因此它们是您需要的地方。

是否可以对其进行编辑以意外或有意更改软件的外观？是的-然后必须以某种方式对它们进行版本控制，为什么当您已经有了完善的解决方案时为什么要使用另一种方法。为什么从黑暗时代开始引入“复制并重命名”版本控制？

当图形设计师的MacBook硬盘驱动器去世时，我已经看到了整个项目的原始图稿变得“糟透了”，这全都是因为某个人拥有无限的智慧，决定“二进制文件不属于转速控制范围”，而图形设计师（至少是这个人） ）的备份往往不太好。

同样适用于所有符合上述条件的二进制文件。

唯一的原因不是磁盘空间。恐怕以100美元/ TB的价格计算，这种借口太薄了。

为什么不呢？:)

是的，存储二进制文件被认为是不好的做法，是的，但是我从不担心图像。

最坏的情况是，如果您有大量货物，请将其存放在其他地方或使用外部组件或扩展程序进行二进制支持。而且，如果图像不会经常更改，那么问题出在哪里？您不会得到很大的肥胖三角洲。而且，如果它们随着时间的流逝而被删除，那么存储历史记录的只是您的服务器，而客户端看不到任何东西。

在我看来，您不必担心-因为您不存储其中的GB。

你能虽然做的，只是Store“源”的图像：SVGs，乳胶宏，等等，并有通过构建系统生成的最终图像。如果可以的话，那可能更好。如果没有，那就不要打扰。

（话虽这么说，Git可以显示文本文件，但不是用于图片的最佳VCS。如果可以，请给我们提供更多上下文和指标）

有关其他信息，您可能需要查看以下问答：

• 在SubVersion / Git中存储图像文件
• 带有非文本文件的Git vs SVN
• 使用Git和Git子模块管理大型二进制文件

这个问题已经很老了，但是这是在处理Git时遇到的一个常见问题，自从上一个答案以来，在将大型文件存储在Git存储库中的现代解决方案上已有了一些进展。

为了在Git中存储大文件，有以下项目：

• git-annex-已经存在了一段时间，但坦率地说，它的复杂性阻碍了它的发展。
• git-media-没有个人经验。似乎也相当复杂。
• git-fit-尝试创建一个更简单的插件。需要S3存储。虽然我很欣赏这个简单性，但是我对插件的主要关注是它是一个未知数，并且由1个人维护（完整披露，我是目前唯一的其他提交者，并且涉及的问题不多）。
• git-lfs-虽然我没有广泛使用它，但这似乎是圣杯。它由Github 提供支持，自2015年10月起可在其所有存储库中使用，并将文件管理的复杂性放在存储存储库的站点上。唯一不足的是，这是相当新的，所以超越Github上没有太多的支持，虽然Gitlab也有支持，如确实Gitea和到位桶已经提到在未来支持。

TLDR：如果可以，请使用git-lfs将图像或其他二进制文件存储在git中。

出于“特定原因”提出了整个“不要在源代码管理中存储二进制文件”：如果您具有可编译的源代码，则不存储实际的编译，而仅存储源代码。图像和视觉资产没有“源”，因此应在版本控制中对其进行跟踪。

我相信使用Git的推荐方法是使用子模块（在Git 1.5.3中引入），该子模块基本上是与主模块相关联的独立存储库。您将图像（和其他二进制资产）存储在子模块中。然后可以根据需要将其与主存储库一起签出或保留。

来自http://book.git-scm.com/5_submodules.html

“ Git的子模块支持允许存储库包含外部项目的签出作为子目录。子模块保持其自身的身份；子模块支持仅存储子模块存储库的位置和提交ID，因此其他克隆包含项目的开发人员（“ “您可以在同一版本中轻松克隆所有子模块。可以对超级项目进行部分检出：您可以告诉Git不克隆任何，部分或全部子模块。”

另外，如果图像不经常更改，尺寸也不是一个重要的问题。您还可以运行命令以修剪/减小大小，例如：

git gc
git gc-aggressive
git prune

是的。

可以说您发布了软件版本1.0。对于2.0版，您决定重做所有带有阴影的图片。因此，您执行此操作，然后发布2.0。然后，一些正在使用1.0且无法升级到2.0的客户决定他们想要使用另一种语言的程序。他们会给您$ 1G来做，因此您可以肯定。但是在不同的文化中，您的某些图片没有意义，因此您必须进行更改...

如果将图像保留在源代码管理中，这很容易，您可以基于1.0对图像进行更改（包括其他操作），构建，发布。如果您在源代码管理中没有这些图像，那么您将遇到很多困难，因为您将不得不找到旧图像，对其进行更改然后再进行构建。

如果它是项目的一部分，则必须在VCS中。如何达到最佳效果可能取决于VCS或组织项目的方式。可能是设计人员的回购协议，而编码人员的回购协议中只有结果，或者只有“图像源”（我曾经有一个仅带有.svg文件的项目，并且图像是通过make / inscape cli生成的）。

但是，如果VCS无法处理或变得无法使用，我会说这不是您工作的正确工具。

到目前为止，我在git中为Web项目放置“通常”数量的图形（模型，概念和页面图形）没有问题。

您是否应该将图像存储在SCM中：是。毫无疑问。

您是否应该将图像存储在git中：这将变得更加棘手。

git非常适合文本文件，但是就其本质而言，二进制文件并不是太热。克隆或推送时，传输的数据大小会出现问题，.git目录会增加，并且合并可能会引起混乱（即，如何合并2张图像！）

一种答案是使用子模块，因为这意味着您的项目和图像之间的链接会更弱-因此，您不必像管理图像一样将其作为源代码的一部分来管理，而仍可对其进行控制，而不必担心将它们分支-假设子项目只是一个“平坦”的数据存储库，在通常的开发过程中不会经历相同的变动。

另一个答案是将它们放置在不同的项目中，从不分支它，并确保提交该项目的每个人都将其立即向上游推送-永远不要让2个人更改文件的相同版本-您会发现这是最困难的git方面不是针对此类非分布式工作流而设计的。您必须使用老式的通信方法来使用此规则。

第三个答案是将它们完全放在另一个SCM中，以便更好地处理图像。

除了@haylem的答案外，请注意大小在其中起着很大的作用。取决于VCS，它可能无法处理大量图像。当克隆或大型推送开始耗费整夜时，这太晚了，因为所有映像都已经在您的存储库中。

规划大图和未来的增长。您不想花两年时间来从事这个项目，而又不想“回购，也许回购规模太大了 ”。

我绝对同意在技术上和经济上存储它们是可行的。我会问“这些图像是运输产品的一部分还是运输产品的内容的一部分？” 不是说您不能在GIT（或任何其他VCS）中存储内容，而是对于单独的VCS来说是一个单独的问题。