0

我一直在研究 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，依此类推。

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

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

4

1 回答 1

1

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

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

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

于 2014-07-01T15:46:40.560 回答