我的构建应该被提交吗？答案

【问题标题】：Should my builds be committed?我的构建应该被提交吗？
【发布时间】：2011-10-06 23:21:48
【问题描述】：

这是一个基于 Web 的项目，其中我的服务器端应用程序代码和客户端 JS/HJTML 处于版本控制之下。假设我发布了 1.0 版，并使用 1.0 版从主干创建了一个新分支。我运行我的构建工具，它会吐出所有压缩和组合的文件。在我的目录结构中，它会生成一个包含压缩/构建文件的构建目录。

我是否应该提交构建目录，以便我拥有每个构建/发布的副本，而无需在需要另一个副本时重新构建它（对于另一台服务器来说..）？

【问题讨论】：

嗨，布鲁克，欢迎来到 Stack Overflow！你把很多问题合二为一；这个网站不仅是关于回答你的问题，而且是关于以一种以后可以对其他人有所帮助的形式来回答你的问题。您为什么不在这里尝试专注于一种思路，并在必要时提出其他单独的问题（您可以超链接）？您可以在上面使用一个小的“编辑”链接:-)

【解决方案1】：

我要说“不”，源代码控制不是编译输出的地方。源代码控制是用于管理源代码 - 目的是为代码存储、版本和提供协作工具。

理想情况下，构建的正确位置是构建服务器。这通常意味着您不仅要捕获编译输出（假设您在构建后保存了人工制品），而且还要捕获重要信息，例如构建参数，这些信息不是通过对构建输出进行版本控制而隐式获得的（除非你的构建脚本也在那里）。

看看The 10 commandments of good source control management 中的数字 8。当然这有点主观（正如一些 cmets 所说明的那样），但就个人而言，我不版本编译输出。也许您需要问的问题是“为什么”要对其进行版本控制以及不这样做会错过什么。

【讨论】：

【解决方案2】：

虽然这是一种主观的回答，但我相信，将构建二进制文件存储在您的版本控制系统中并不常见。这就是标签的真正目的。

在发布时，您应该创建一个包含构建脚本在内的完整代码状态的标签，并带有当前版本号的标签。在任何时候需要早期版本的副本时，只需检查标记版本并进行构建即可。该标签包含在该阶段完全复制构建所需的所有信息和代码状态。

如果您希望将构建保存在其他地方，那是另一回事，完全取决于您。最常见的是它们不属于版本控制。

【讨论】：

【解决方案3】：

在版本控制下保持构建输出通常是一个好主意。它允许将输出存储在镜像输入的结构中。这清楚地表明了哪个输入产生了哪个输出。它还允许轻松访问任何版本的输出，而无需重新构建。

将其视为选项的原因主要与存储库相关。原因包括存储库太小、访问速度太慢或只是不喜欢在存储库中有输出文件。

但总的来说，这样做本身并没有什么坏处。在许多情况下，它很有价值。

【讨论】：