从 master 或 hotfix 部署到生产环境？答案

【问题标题】：deploy to production from master or hotifx?从 master 或 hotfix 部署到生产环境？
【发布时间】：2013-12-04 02:36:46
【问题描述】：

在使用了几年的 SVN 之后，我们正在公司中采用 Git。 git 流与 master/hotfix/develop/release 分支非常适合我们的需求。到目前为止，一切都很顺利，除了一个难题。我们的项目是一个用于 weblogic 的 Java 应用程序，我们在项目构建时生成一个 WAR 文件。

上下文是：

我们将 master 作为主干，用于保存用于生产的代码
从 master 分支出一个新的修补程序
开发人员提交修补程序
QA 测试修补程序
二进制文件已通过 QA 批准

最大的问题是：

我们应该将二进制文件从修补程序部署到生产环境吗？
或者我们应该合并到 master，从那里构建，测试然后部署到生产环境？

我知道 master 将是保存用于生产的代码的分支。所以我在从修补程序部署时遇到问题。然而，从 master 部署意味着 2 个 QA 周期在与 2 个构建（在修补程序和 master 上）相同的代码库上可能会根据 maven 依赖项/构建环境/... 在同一个代码库上进行 2 个 QA 周期是一种资源浪费。

我在网上搜索并发现很少有关于此的参考资料。在这里和那里我看到有人说他们从 master 部署，而其他人从 hotfix 部署。问题是从 master 部署的人通常在一个已解析的语言项目（PHP、Perl、...）上，所以他们不需要考虑二进制文件。

你们中有人遇到过这个问题吗？你采取了什么方法？

提前致谢！

【问题讨论】：

标签： java git deployment git-flow

【解决方案1】：

为一个小补丁分支出一个短期发布分支的意义在于，您可以准确地选择应用到已知状态的内容。您可能有一个 1.0.0 版本，但您需要一些错误修复来制作 1.0.1。在这种情况下，从 1.0.0 分支并应用您的错误修正并从那里发布是有意义的。

从发布分支合并到 master 并从那里进行发布也可以，但提出了一个问题，即为什么要首先创建分支以及这是否真的是一个修补程序。从质量的角度来看，最好在目标分支上进行开发，而不是孤立地工作并最终进行最终合并——因为正如您所说，您需要两个 QA 周期。

要问的问题似乎是您是否希望严格控制新版本中包含哪些提交，或者您是否对包含该组提交的任何版本感到满意。

我不清楚部署类型（未编译的脚本语言与编译的语言）如何与讨论相关。

【讨论】：

我在网上看到的资料上注意到，由于 PHP/... 的解析性质，从 hotfix 或 master 释放的区别是没有的，因为文件将在服务器，但这是一个远景。我明白你在修补程序上开发的观点，与我的团队在这里使用的相同。关于这个问题，我相信这比实际问题更能让人安心。我想确保我可以在 1 年的时间内回到历史，并能够从 master 生成构建。由于我还没有从 master 部署，我对 master 代码的信心降低了。明白我的意思了吗？
并非如此。一年后构建是否可重现与发布来自哪个分支无关，即发布标签指向的位置。无论哪种方式，这只是一个承诺。它甚至不知道它属于哪个分支。

【解决方案2】：

这是一篇关于 git 分支的优秀文章 - 希望对您有所帮助

来源：http://nvie.com/posts/a-successful-git-branching-model/

【讨论】：

我很熟悉这个@dekdev，谢谢！但是例如，您可以在 Tag 0.2 上看到。潜在的二进制文件是在合并到 master 之前在红色修补程序提交上推送到生产，还是在合并后在 master 上推送？如果在 hotfix 上，那我们为什么不在 hotfix 上而不是 master 上标记 0.2？
实际上，在链接上我读到：“因此，每次将更改合并回 master 时，根据定义，这是一个新的生产版本。我们对此往往非常严格，因此理论上，我们可以使用 Git 钩子脚本来自动构建我们的软件并将其推出到我们的生产服务器上，每次在 master 上进行提交。”
该图没有显示部署；只有分支和合并策略，OP 没有询问。