mvn jgitflow:release-finish 正在合并发布 --> 主 --> 开发

Question

当我使用

mvn jgitflow:release-finish

我注意到 release 分支合并到 master 分支。

问题：这是正确的方法吗？

抱歉，我的问题可能很幼稚，因为我是新手。我在想来自 release 分支的代码将合并到 develop 和 master 而不是 release --> master --> develop。

问题：如果我不希望这种情况发生，而是我应该能够从 master 进行 rebase 开发，该怎么办？

Answer 1

当我使用 mvn jgitflow:release-finish 时，我注意到 release 分支被合并到 master 分支中。这是正确的方法吗？

根据gitflow背后的主要哲学，这是正确的方法：

发布分支

• 可以从以下分支：develop
• 必须合并回：develop和master

根据插件文档，release-finish确实合并回 master 和 dev 分支：

完成发布 - 运行 Maven 构建（部署或安装），合并发布分支，使用开发版本更新 pom(s)

这是有道理的，因为（再次回到gitflow）：

当发布分支的状态准备好成为真正的发布时，需要执行一些操作。首先，发布分支被合并到 master 分支（因为 master 上的每个提交根据定义都是一个新版本，请记住）。接下来，必须标记 master 上的提交，以便将来轻松引用此历史版本。最后，在发布分支上所做的更改需要合并回开发，以便未来的版本也包含这些错误修复。

我在想来自 release 分支的代码将合并到 develop 和 master 而不是 release --> master --> develop。

顺序遵循这个流程（先主，然后开发），因为它是一个发布，作为一个发布，它必须首先转到主（它应该始终代表已发布的代码库），然后开发（这是下一个潜在的发布代码库） .

如果我不希望这种情况发生，而是我应该能够从 master 进行 rebase 开发，该怎么办？

您可以使用以下noReleaseMerge选项：

是否关闭从发布分支到 master 和 develop 的合并更改

默认值为 to false，因此默认情况下执行合并。但是，该选项涵盖了两个合并，您不能只禁用其中一个，要么两者都禁用（再次遵循 gitflow 哲学），要么都不禁用。此选项可能适合您的需要，但您随后将通过 git 命令执行其他操作。