我应该版本控制我的jQuery插件的缩小版本吗？

Question

假设我写了一个jQuery插件并将其添加到我的存储库（在我的案例中为Mercurial）。这是一个单独的文件，比如jquery.plugin.js。我正在使用BitBucket来管理这个存储库，它的一个功能是下载页面。因此，我添加jquery.plugin.js作为下载之一。

现在我想提供我的插件的缩小版本，但我不确定最佳做法是什么。我知道它应该在“下载”页面上以jquery.plugin.min.js的形式提供，但是每次我更新时都应该对其进行版本控制以反映未公开的版本吗？

我看到控制缩小版本的版本最明显的问题是每次我更改未公开的版本时我都会忘记更新它。

那么，我应该控制缩小的文件吗？

Answer 1

不，您不需要在源代码管理下保持生成的最小化版本。

我们在将生成的文件添加到源代码控制（TFS）时遇到了问题，因为TFS将本地文件设置为只读方式。生成文件作为构建过程的一部分的工具会出现写入访问问题（这可能不是其他版本控制系统的问题）。

但重要的是，所有：

• 工具
• 脚本
• 源代码
• 资源
• 第三方图书馆

以及构建，测试和部署产品所需的任何其他内容都应受版本控制。

您应该能够从源代码管理中检出特定版本（通过标记或版本号或等效版本），并完全按照该时间点重新创建软件。即使在“新鲜”机器上也是如此。

构建不应该依赖于任何不受源代码控制的东西。

脚本：build-scripts是否为ant，make，MSBuild命令文件或您正在使用的任何内容，以及您可能需要在版本控制下进行的任何部署脚本 - 而不仅仅是在构建计算机上。

工具：这意味着编译器，最小化器，测试框架 - 构建，测试和部署脚本工作所需的一切 - 应该受源代码控制。您需要这些工具的确切版本才能重新创建到某个时间点。

这本书“Continuous Delivery”教会了我这一课 - 我强烈推荐它。

虽然我相信这是一个好主意 - 并尽可能坚持下去 - 但在某些方面我并不是100％肯定。例如操作系统，Java JDK和持续集成工具（我们使用的是Jenkins）。

您是否实践持续集成？这是一个很好的方法来测试你是否掌控了上述所有内容。如果在构建软件之前必须在Continuous Integration机器上进行任何手动安装，可能会出现问题。

Answer 2

我的简单经验法则：

这可以在构建过程中自动生成吗？

1. 如果是，则它是资源，而不是源文件。不要检查它。
2. 如果不是，则它是源文件。检查一下。

Answer 3

以下是我自己使用的“存储库的合理规则”：

1. 如果需要将blob作为源包的一部分进行分发以构建它，使用它，或者在源代码树中对其进行测试，那么它应该受版本控制。
2. 如果可以根据需要从版本化源重新生成资产，请执行此操作。如果你可以（GNU）制作它，（Ruby）耙它，或者只是假冒它，不要将它提交到你的存储库。
3. 您可以使用版本化的符号链接，维护脚本，子模块，外部定义等来区分差异，但结果通常不令人满意且容易出错。必要时使用它们，并尽可能避免使用它们。

这绝对是一种情况，你的里程可能会有所不同，但三个合理规则对我来说效果很好。