Gitflow：将版本错误修正合并回主版

Question

我的问题是围绕gitflow流程中的一个非常具体的点（如文档here所述）。

我已将release/1.2的错误修正合并到master，并进行了适当标记。

除了历史记录的外观之外，从release/1.2反向合并与从master反向合并到develop之间的区别是什么。

我尝试了两种方式，在我简单，人为的例子中，我发现develop没有任何区别，正如我所料。

这有危险吗？我以后会遇到麻烦的问题吗？我错过了一些明显的东西吗我怀疑答案可能与已进入master的其他功能有关，但目前应暂时不在develop范围内。

合并发布版本：

合并大师以开发：

Answer 1

如果将master合并回您的开发中，您将在开发分支中拥有所有merge branch release/x.y into master合并提交，而在合并release/x.y分支本身时，您只能获得真实变化。

当然，这或多或少是一个美容问题。但合并方向通常只从develop到master，而不是相反。

除了所说的合并提交你的develop分支之外没有真正的危险。如果您坚持使用此流程，则master中的功能永远不会出现在develop中，因为热修复和发布分支应始终合并到您的develop以及在master。

Answer 2

  

我怀疑答案可能与已经进入master的其他功能有关，但目前应暂时不在develop范围内。

从master提交进入develop并进行下一个修补程序合并。如果存在真正的代码更改，则可能会出现意外结果并扭曲hostfix内容。

将稳定分支（gitflow中的master）合并到开发分支（gitflow中的develop）在各种git工作流中是已知的方式。 Bbitbucket Server（由Atlassian出售的商业解决方案）具有Automatic branch merging的特征。由于存在一些错误修正，Git项目本身总是将分支maint合并到master。

所以我真的没有看到为什么gitflow的作者选择了另一种方式。可能没有真正的理由，这只是一个偶然的决定。

Answer 3

<块引用>

这样做有危险吗？我以后会遇到麻烦的问题吗？我是否遗漏了一些明显的东西？

没有危险；没有问题;你不会错过任何东西。将 master 合并回 develop 是（恕我直言）稍微更好的方法，并且没有任何缺点。无论您选择哪种方式，您最终都会在 develop 中获得相同的合并提交总数。区别仅在于这些合并提交何时结束。如果您先将 release 合并回来，您不会在稍后获得所有 release 到 master 合并提交，在您进行修补程序时一次性完成。如果您执行 master 返回 develop，您会立即看到最近的合并提交。但是将 master 合并回 develop 有更大的优势：

始终确保 master 中的所有更改也在 develop 中或 release 中（当它存在时）很重要。 （它们不同步的唯一时间是在 release 或 hotfix 分支完成期间。）也许确认 master 已同步的最简单方法是确保master 中的提示（最高提交）始终在 develop 中，或者 release（如果存在）。您可以轻松编写脚本以定期运行，并在不正确时通知您。如果您不能期望 master 的提示提交永远在 release 中，那么该脚本会更加复杂。