gitflow 热修复分支与长期发布分支

Posted 2023-03-06

【中文标题】gitflow 热修复分支与长期发布分支

【英文标题】：gitflow hot fix branch vs long lived release branch

【发布时间】：2014-07-01 14:25:44

【问题描述】：

我一直在研究 gitflow 工作流程http://nvie.com/posts/a-successful-git-branching-model/，它是有道理的，并且与我过去所做的非常相似。在发布和热修复方面，我做了一些不同的事情，并想问一下 gitflow 分支方式与我提出的方式的优缺点。

通常，当我创建发布分支时，例如发布 1.0.0，我会将发布分支命名为 release-1.0.x，而不是 release-1.0.0。一旦我创建了分支（但在代码发布之前），版本将是 1.0.0-SNAPSHOT，用于任何最后一分钟的修复。当我发布时，我创建 1.0.0 的发布版本，标记它并合并到 master。现在我没有删除发布分支，而是将版本增加到 1.0.1-SNAPSHOT。这有效地成为了 1.0.x 系列的长期热修复分支。如果我在生产中发现错误，我会在这个分支上修复它，删除 1.0.1 发布版本并将版本增加为 1.0.2-SNAPSHOT，等等。

缺点是只要此版本是当前版本，发布分支就存在。好处是，如果有错误，我不需要创建新的热修复分支，并且分支已经存在。

所以我的问题是我是否因为没有热修复分支并以这种方式这样做而遗漏了任何重大问题？

【问题讨论】：

我也在寻找有关此策略的意见。我们正在进行 android 应用程序开发，只要我不创建另一个发布分支，我就会保持发布分支打开。不需要修补程序分支。非常方便。

【参考方案1】：

我们在工作中采用了 nvie 模型，并且效果很好。

此修补程序仅用于已发布软件的次要补丁 - 在它们合并到主补丁并删除之前将有很短的生命周期。同时，开发分支用于进行重大改进。

我认为 nvie 模型的（次要）优势是修补程序分支的生命周期短。在一个团队中，我可以看到准备好修补程序分支以供他们在需要时使用的优​​势。

【讨论】：

我可以看到保持分支寿命短的优势。它可以防止痛苦的合并。即使我们在发布分支上进行修复后立即合并，也可能没有真正的理由保留它，我们可以只使用修补程序分支。