缩小的CSS是否应该存储在Git中？

我使用Gulp从我正在处理的项目的SASS代码中生成缩小的CSS。

我想知道从Git上线时重新生成此缩小的CSS是否被认为是最佳实践...

要么

要将缩小的CSS文件存储在Git中，以便将它们自动实时发布到生产环境，而无需服务器方面的进一步工作？

我很感谢人们对此的想法。谢谢！

“这取决于。” 对于正常的开发跟踪，没有。但是，对于云和DevOps部署，这通常很方便，甚至是必需的。

在大多数情况下， @ptyx是正确的。确实，他的“不”可以更加强调。像“不，不！天哪！ ”之类的东西

为什么不将缩小或压缩的资产存储在Git等源代码控制系统中？

1. 它们几乎可以通过您的构建过程从源代码快速地重新生成。存储压缩资产基本上是将相同的逻辑内容存储两次。它违反了“不要重复自己”（又称DRY）原则。

2. 从哲学上讲却不那么实际，但更实际的原因是，最小化/优化的资产在存储在Git中时可压缩性很差。源代码控制系统通过识别所存储的每个文件的不同版本之间的更改（“增量”）来工作。为此，他们会将最新文件与先前版本“差异化”，并使用这些增量来避免存储文件每个版本的完整副本。但是，在“最小化/优化”步骤中进行的转换通常会消除差异/增量算法使用的相似点和航路点。最简单的例子是删除换行符和其他空格。由此产生的资产通常只是一条长线。Web构建过程的许多部分，例如Babel，UglifyJS，Browserify，Less和Sass / SCSS积极地改变资产。它们的输出是微扰的。较小的输入变化会导致输出的重大变化。结果，diff算法经常会相信每次都看到几乎完全不同的文件。结果，您的存储库将更快地增长。您的磁盘可能足够大，网络也足够快，这不是一个大问题，尤其是如果有必要将缩小/优化的资产存储两次的话-尽管基于第1点，多余的副本可能只是100％没有意义肿。

但是，有一个主要例外：DevOps /云部署。许多云供应商和DevOps团队使用Git和类似工具不仅跟踪开发更新，而且还积极部署其应用程序和资产以测试和生产服务器。在这个角色中，Git能够有效确定“哪些文件已更改？”的能力。与更精确地确定“每个文件中发生了什么变化”一样重要。如果Git必须为缩小/优化的资产做几乎完整的文件副本，那会比原本要花费更长的时间，但是没什么大不了的，因为它仍然做得很好，有助于避免在每个项目上都复制“项目中的每个文件”部署周期。

如果您将Git用作部署引擎，则在Git中存储最小化/优化的资产可能会从“否”切换。令人满意。的确，例如，如果您在要部署到的服务器/服务上缺少可靠的构建/后处理机会，则可能需要这样做。（在这种情况下，如何对开发和部署资产进行分段是一个单独的蠕虫罐。到目前为止，足以知道可以通过几种方法进行管理，包括使用单个统一存储库，多个分支，子存储库，甚至多个重叠存储库。 ）

没有。

源代码控制只能包含源代码。如果它是从源代码生成的，那么它就不属于那里-应该由您的构建过程生成。

您不希望获得源代码来控制中间构建工件的根本原因是，如果您这样做了，那么很难相信正在运行的内容是来自刚刚修改的源，还是来自您未能重建的中间产品。