这是一个基于 Web 的项目，我的服务器端应用程序代码和客户端 JS/HJTML 处于版本控制之下。假设我发布了 1.0 版，并使用 1.0 版从主干创建了一个新分支。我运行我的构建工具，它会吐出所有压缩和组合的文件。在我的目录结构中，它会生成一个包含压缩/构建文件的构建目录。
我是否应该提交构建目录，以便我拥有每个构建/发布的副本而无需重新构建它，如果我需要另一个副本（对于另一台服务器来说..）？
问问题
186 次
3 回答
3
虽然这是一个主观的答案，但我相信在你的版本控制系统中存储构建二进制文件并不常见。这就是标签的真正目的。
在发布时，您应该创建一个完整代码状态的标签，包括构建脚本，并带有当前版本号的标签。在任何时候需要早期构建的副本时，检查标记版本并构建它是一件简单的事情。该标签包含在该阶段准确复制构建所需的所有信息和代码状态。
如果您想将构建保存在其他地方，那是另一回事，完全取决于您。最常见的是它们不属于版本控制。
于 2011-07-17T15:29:10.827 回答
1
将构建输出保持在版本控制之下通常是一个好主意。它允许将输出存储在镜像输入的结构中。这清楚地表明了哪个输入产生了哪个输出。它还允许轻松访问任何版本的输出而无需重建。
将其视为选项的原因主要与存储库相关。原因包括存储库太小，访问速度太慢，或者只是不喜欢在存储库中有输出文件。
但总的来说，这样做本身并没有什么坏处。在许多情况下，它是有价值的。
于 2011-07-17T16:09:02.277 回答
1
我要说“不”，源代码控制不是编译输出的地方。源代码控制是用于管理源代码 - 目的是存储、版本和为代码提供协作设施。
理想情况下，构建的正确位置是构建服务器。这通常意味着您不仅要捕获编译输出（假设您在构建后保存了人工制品），而且还要捕获重要信息，例如构建参数，这些信息不是通过对构建输出进行版本控制而隐式获得的（除非你的构建脚本也在那里）。
看看良好源代码控制管理的 10 条诫命中的第8 条。当然这有点主观（正如一些评论所说明的那样），但就个人而言，我不版本编译输出。也许您需要问的问题是“为什么”要对其进行版本控制以及不这样做会错过什么。
于 2011-07-18T06:43:56.453 回答