0

我正在使用 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 单独。

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

4

1 回答 1

0

您在这里触及的是 a 的概念support branch。在这里,一旦您开始在 2.x 上工作,但需要继续在早期版本上进行开发,您需要为 1.x 开发创建一个支持分支。

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

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

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

于 2017-03-15T16:14:30.427 回答