当我使用时
mvn jgitflow:release-finish
我注意到发布分支已合并到主分支中。
问题：这是正确的方法吗？
对不起，我的问题可能很天真，因为我是新手。我以为来自发布分支的代码将合并以开发和掌握，而不是像发布 - ＆gt;主人 - ＆gt;发展。
问题：如果我不希望这种情况发生，而我应该能够从主人那里重新发展，那该怎么办？
答案 0 :(得分：2)
当我使用mvn jgitflow：release-finish时，我注意到发布分支已合并到master分支中。这是正确的方法吗？
根据背后的主要哲学gitflow：
，这是正确的方法发布分支
- 可能会从
分支出来develop- 必须合并回：
develop和master
根据插件documentation，release-finish确实合并回master和dev分支：
完成发布 - 运行maven构建（部署或安装），合并发布分支，更新pom（s）和开发版本
这是有道理的，因为（再次回到gitflow）：
当发布分支的状态准备好成为真正的版本时，需要执行一些操作。首先，release分支合并为master（因为master上的每个提交都是定义的新版本，请记住）。接下来，必须标记master上的提交以便将来参考此历史版本。最后，在发布分支上进行的更改需要合并回到develop中，以便将来的版本也包含这些错误修复。
我在想，发布分支的代码将合并为开发和掌握而不是像发布 - ＆gt;主人 - ＆gt;发展。
顺序遵循这个流程（第一个主人，然后开发），因为它是一个发布，作为一个发布它必须首先去master（它应该总是代表已发布的代码库），然后开发（哇是下一个潜在的发布代码库。
如果我不希望这种情况发生，那么我应该能够从主人那里改变发展方式。
您可以使用noReleaseMerge选项：
是否关闭从发布分支到主控和开发的合并更改
默认值为false，因此默认情况下会执行合并。但是，该选项涵盖了两个合并，您不能只禁用其中一个，它既可以是两个（再次，遵循gitflow哲学），也可以不是。此选项可能适合您的需要，但您可以通过git命令执行其他操作。