在大多数情况下，图像不会更改。包含它们的文件夹只会随着添加图像的大小而增加。令人担忧的是，随着时间的推移，大型或大型图片的组合可能会使图片文件夹的尺寸增大。
这被认为是最佳做法吗？还有什么其他替代方案可以共享分布式团队可以轻松访问的项目中所需的二进制文件？
#1 楼
您的图像是原始作品，还是可以从其他地方恢复（保证？）？他们需要运送从源头构建的软件单元吗？如果它们是原始的，则需要备份。将它们放在版本控制中，如果它们从不更改，则空间损失与备份相同，并且它们就在您需要的位置。
是否可以对它们进行编辑以意外或有意更改软件的外观？是的-然后必须以某种方式对它们进行修订控制，为什么在您已经拥有完善的解决方案时为什么要使用另一种方法。为什么从黑暗时代开始引入“复制并重命名”版本控制？
我看到图形设计师的MacBook硬盘驱动器去世时，整个项目的原始图稿变得“糟透了”，这全都是因为有无限智慧的人认为“二进制文件不属于转速控制”，和图形设计人员（至少这一个）往往不太适合备份。
同样适用于所有符合上述条件的二进制文件。
唯一的原因不是磁盘空间。恐怕以100美元/ TB的价格计算，这种借口太少了。
评论
顺便说一句：互联网不是可靠的来源。如果您是从“ bobsfreestuff.com”下载的图片，那么下周可能会消失了。
–mattnz
2011年6月2日，下午1:59
+1-且应为+ more。版本控制的重点是允许您在过去的某个时间恢复/回滚到任何内容。获得100％的唯一方法是，您可以及时收回当时应有的一切，从而将所有内容置于版本控制之下。那就是源，图像，资源，有用/支持的PDF。哎呀，我什至还放了压缩CD映像。甚至我都知道将VM虚拟机（包括VMDK）放入源代码管理中。似乎极端？ 2年后保存了我的培根。
–quickly_now
2011年6月2日下午4:06
100％同意。如果图像是软件的一部分，则需要对其进行修订控制。
–迪恩·哈丁（Dean Harding）
2011年6月2日在8:44
我不同意的唯一原因是，如果这样做使您的存储库繁琐而难以复制，以至于开发人员不得不真正想到“我真的想花时间克隆它，还是可以在另一个分支中执行X”。如果发生这种情况，请确保事情能很快重新组织
–布鲁克
2011年6月2日13:29
+1表示需要部署。如果由于我是新团队成员或其他成员而克隆了您的存储库，则它应该开箱即用。这确实包括使makefile等效文件足够聪明，以便在必要时获取必要的第三方库。
– Spencer Rathbun
2012年3月6日20:14
#2 楼
为什么不呢？ :)存储二进制文件被认为是不好的做法，是的，但是我从不担心图像。
最坏的情况是，如果您有很多东西，请将它们存储在其他地方或使用外部或二进制支持扩展。而且，如果图像不会经常更改，那么问题出在哪里？您不会得到很大的肥胖三角洲。而且，如果它们随着时间的流逝而被删除，那么只有您的服务器会遭受历史记录的困扰，但是客户端看不到任何东西。
我认为，您不必担心-当然，您只可以存储“源”图像：SVG，LaTeX宏等，并具有由构建生成的最终图像。系统。
如果可能的话，那就更好了。如果不是，那么就不要打扰。
（话虽如此，Git可以显示文本文件，但不是用于图片的最佳VCS。如果可以，请给我们提供更多的上下文和指标）
有关其他信息，您可能需要查看以下问答：
将图像文件存储在SubVersion / Git中
Git vs SVN with非文本文件
使用Git和Git子模块管理大型二进制文件
评论
+1用于存储源代码，但是如果他们可以在没有完整版本的情况下进行开发测试，则可能会使其混乱。这也意味着您需要在早上开始工作之前先构建所有图像。
–TheLQ
2011年6月2日，下午1:56
@DantheMan：en.wikipedia.org/wiki/Binary_file
– Haylem
2014年7月1日在9:31
“为什么不呢？” -因为如果您的回购超过2GB，Bitbucket（我也曾在Github上尝试过）会拒绝您的回购。因此，如果您要打包大量图像，请准备好托管自己的存储库。
–杰兹
2015年9月3日在7:41
@Jez：“最糟糕的情况是，如果您有大量货物，请将其存放在其他地方，或者使用外部或二进制支持扩展名。”并且“您不必担心-准许您不要存储其中的GB。”有点说：)显然，如果您开始存储大量二进制数据，那是个坏主意。对于大多数小型项目或中型项目而言，它们只创建一次图像，并且在项目的整个生命周期内变化不大，这是可以接受的。虽然仍然不是真正的粉丝，但是如果需要它们的话，可以进行复杂的构建设置。我的偏好始终是基于文本的图像源。
– Haylem
2015年9月7日13:23在
对于SVG等人的建议，+ 1。这不是我要找的答案，而是我需要的答案:-)
– MartinBøgelund
19年6月19日在7:39
#3 楼
这个问题已经很老了，但是这是在处理Git时出现的一个常见问题，自从上一个答案以来，在将大型文件存储在Git存储库中的现代解决方案上已有了一些进展。用于存储大文件Git中的文件有以下项目：
git-annex-已经存在了一段时间，但坦率地说，它的复杂性妨碍了它。
git-media-没有个人经验。似乎也相当复杂。
git-fit-尝试创建更简单的插件。需要S3存储。虽然我很欣赏这个简单性，但是我对插件的主要关注是它是一个鲜为人知的问题，并且由1个人维护（完整披露，我是当时唯一的其他提交者，并且是一个琐碎的问题）。
git-lfs-虽然我没有广泛使用它，但这似乎是圣杯。它由Github提供支持，自2015年10月起可在其所有存储库中使用，并将文件管理的复杂性放在存储存储库的站点上。唯一的缺点是，这是相当新的东西，因此，除了Github之外，它没有太多支持，尽管Gitlab和Gitea也都提供了支持，而Bitbucket也暗示将来会提供支持。
TLDR：如果您可以使用git-lfs将图像或其他二进制文件存储在git中。
评论
很长时间以来，我第一次很高兴能向下滚动阅读投票率较低的答案。 git lfs正是我想要的，Atlassian甚至在BitBucket Server中添加了对它的支持！如果我能对此投票一百万次，那我会。
– jonnybot
16年4月4日在20:54
@jonnybot，谢谢。我的回答很晚，所以我没有太多的知名度，但是我自己使用git-lfs之后，它认为这是将二进制文件存储在git中的最好的当前解决方案。
–詹姆斯·麦克马洪
16年2月9日在22:52
#4 楼
出于特定原因提出了整个“不将二进制文件存储在源代码控制中”的说明：如果您具有可编译的源代码，则不存储实际的编译，而仅存储源代码。图像和视觉资产没有“源”，因此应在版本控制中对其进行跟踪。评论
有时，视觉资产具有“类似于源代码的东西”，那么最好将创建最终输出的过程自动化，并且仅将源代码存储在版本控制中。例如：由SVG文件制成的光栅图形版本，从Sprite表中切出的网站资产。
– Tanius
18 Mar 20 '18在21:45
正确，这是一个完全公平的论点。
–Jason T Featheringham
18/12/11在19:10
#5 楼
我相信使用Git的推荐方法是使用子模块（在Git 1.5.3中引入），该子模块基本上是与主模块相关联的独立存储库。您将图像（和其他二进制资产）存储在子模块中。然后可以根据需要将其检出到主存储库中，也可以将其保留。从http://book.git-scm.com/5_submodules.html
“ Git的子模块支持允许
存储库包含一个
外部项目的签出作为
子目录。子模块保持
自己的身份； submodule
支持仅存储子模块
存储库位置和提交ID，因此
其他克隆包含项目的
开发人员（“ superproject”）
可以轻松克隆所有相同版本的
子模块。可以对超级项目进行部分检出：您
可以告诉Git不克隆任何子模块，也不克隆所有子模块。“
此外，如果图像不经常更改，尺寸也不应该成为重要问题。您还可以运行命令以修剪/缩小大小，例如：
git gc
git gc-aggressive
git prune
#6 楼
是的。假设您发布的软件版本为1.0。对于2.0版，您决定重做所有带有阴影的图片。因此，您执行此操作，然后发布2.0。然后，一些正在使用1.0且无法升级到2.0的客户决定要他们使用另一种语言的程序。他们会给您$ 1G来做，因此您可以肯定。但是在不同的文化中，您的某些图片没有意义，因此您必须对其进行更改...
如果将图像保留在源代码管理中，这很简单，基于1.0，更改图像（以及其他），构建，发布。如果您在源代码管理中没有这些图像，那么您将遇到很多困难，因为您将不得不找到旧图像，对其进行更改然后再进行构建。
#7 楼
如果它是项目的一部分，则必须位于VCS中。如何达到最佳效果可能取决于VCS或组织项目的方式。也许是设计人员的回购协议，而编码人员的回购协议中只有结果，或者只有“图像源”（我曾经有一个项目只有一个.svg文件，而图像是通过make / inscape cli生成的）。 br />但是，如果VCS无法处理或变得无法使用，我会说这不是您工作的正确工具。
到目前为止，我没有遇到任何问题将用于Web项目的“正常”数量的图形（模型，概念和页面图形）放入git。
#8 楼
您是否应该将图像存储在SCM中：是。毫无疑问。您应该将图像存储在git中吗？这会变得更加棘手。
git对于文本文件非常有用，但是从本质上来说并不是太好二进制文件很热。克隆或推送时，传输的数据大小会出现问题，.git目录会增加，并且合并可能会引起混乱（即，如何合并2张图像！）
一个答案是使用子模块，因为这意味着您的项目和图像之间的链接会更弱-因此，您不必像管理图像一样将其作为源代码的一部分来管理，而仍然保持对它们的控制，而不是对其分支进行担心-假设子项目只是一个“扁平”数据存储库，在正常的开发过程中不会经历相同的变动。
另一个答案是将它们放在一个不同的项目，永远不要分支它，并确保提交该项目的每个人都将其立即向上游推送-永远不要让2个人更改文件的相同版本-您会发现这是最困难的方面，因为git并非为此设计的非分布式工作流程。您必须使用老式的通信方法来遵守此规则。
第三个答案是将它们完全放在另一个SCM中，以便更好地处理图像。
#9 楼
除了@haylem的答案外，请注意大小在其中起很大的作用。取决于VCS，它可能无法处理大量图像。当克隆或大型推送开始耗费整夜时，这太晚了，因为所有映像都已经在您的存储库中。计划大图和未来的增长。您不想花两年时间来从事这个项目，而又不想“回购，也许回购规模太大了”。
评论
您的答案有点无关紧要，因为问题是特定于git的。您是否知道大小是否对git存储库起着很大的作用？
– yannis
2011年6月2日在2:02
@Yannis必须错过第一句话... AFAIK，对于较大的存储库，git更好，但是大小问题仍然存在，因为巨大的克隆或推送是一个问题
–TheLQ
2011年6月2日，下午2:42
如果碰巧成为问题，使用GIT可以很容易地重新排列存储库并创建部分克隆等。不要混淆数十年前的修订控制工具与今天的历史。
–mattnz
2011年6月2日，下午3:43
评论
当您说“图像”时，我们是在谈论26mb DSLR Raw文件，1mb 3d游戏纹理还是<100k png图标？ （我打算回答“取决于”，但我会避免）@布鲁克：我有点假设我们在谈论网站的图标或小型图形元素。游戏纹理，图形设计原始文件或用于文档编辑的精确图形可能是另一回事了，
我个人认为他指的是ISO图像，而不是图片。
它实际上应该用于中小型Web友好图像。令人担心的是，当我认为应该使用其他一些东西时，一些开发者将开始在其中粘贴每个大型原始图像。
今天读这个问题？在git lfs上查看下面的答案。这可能是您想要的。 developers.stackexchange.com/a/306882/92506