使用 GitFlow 时的 jgitflow 和并行发布

Question

我正在使用 jgitflow Maven 插件根据 GitFlow 进行发布。这工作正常。当我的发布延迟时会出现问题，所以我必须同时发布 2 个版本。

让我们考虑一个例子。

根据 GitFlow，我必须将我的生产状态提交给 master 分支。因此，我将 1.0、1.1、1.2 版本合并到 master。 总有一天 2.0 版本开始了。我需要将 2.0 版本提交给 master。但是如果 1.xx 还没有完成呢？

在 2.0 之后提交 1.xx 看起来是一种不好的做法，并且可能会导致合并冲突。

所以我的想法是

1. 为从上一个 1.xx 版本分支的 1.xx 创建假开发分支。让我们称之为 1.11dev

2. 从该分支运行 1.xx jgitflow 版本并将它们不再合并到 master，而是再次合并到从上一个 1.xx 版本创建的伪造 master 分支，我们称之为 1.11master

3. 从 master 分支运行 2.xx 版本并将它们正常合并到 master。

这意味着我的主分支将仅包含 1.xx 版本的一部分。这不好。 这也意味着我必须将 1.xxdev 中的修复分别合并到 'true' dev。

我的理解正确吗？ 有没有更好的办法？

Answer 1

您在这里谈到的是support branch 的概念。在这里，一旦您开始使用 2.x，但需要继续开发早期版本，您需要为 1.x 开发创建一个支持分支。

我们已经在 GitVersion 工具中介绍了这一点，这里有一些支持文档：

http://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

底线是，一旦你到达这一点，你实际上是在运行两个 gitflow 实例。一个用于活动开发分支，另一个用于支持分支。