如果你把master合并回你的develop分支，你会在develop分支中得到所有的merge branch release/x.y into master合并提交，而当合并release/x.y分支本身时，你只得到真实的的改变。
当然，这或多或少是一个表面问题，但是合并方向通常只是从develop到master，而不是相反。
没有真实的的危险，除了上述合并提交会使您的develop分支混乱。如果您坚持流程，master中不应该有develop中没有的特性，因为热修复和发布分支应该总是合并到您的develop和master中。

我怀疑答案可能与master中的其他特性有关，但这些特性目前应该不在develop中。
无论如何，来自master的提交将进入develop，并进行下一个修补程序合并。如果存在真实的的代码更改，则可能会出现意外结果并扭曲主机修补程序内容。
将稳定分支（gitflow中的master）合并到开发分支（gitflow中的develop）在各种git工作流中是已知的方法。Bbitbucket Server（Atlassian正在销售的商业解决方案）有Automatic branch merging的特性。Git项目本身总是将分支maint合并到master，因为有一些bug修复。
所以我真的不明白为什么gitflow的作者选择了另一种方式，可能是没有真正的理由，这只是一个偶然的决定。

这样做有危险吗？我以后会遇到混乱的问题吗？我错过了一些明显的东西吗？
没有危险;没有问题;并且您不会遗漏任何内容。将master合并回develop（恕我直言）稍微好一点的方法，并且没有缺点。无论你选择哪种方式，你最终都会得到develop中相同的合并提交总数。区别只是那些合并提交在那里结束的时间。如果你先将release合并回来，你就不会'不要等到以后才能得到所有的release到master合并提交，当你做一个热修复的时候，一次就可以得到所有的合并提交。如果你做master回到develop，你会马上看到最近的合并提交。但是把master合并回到develop还有一个更大的好处：
在任何时候，确保master中的所有更改也在develop或release中（如果存在）都很重要。（它们唯一不同步的时间是在完成release或hotfix分支期间。）确认master是否同步的最简单方法可能是确保提示（top commit）in master总是在develop，或者release，如果它存在的话。你可以很容易地编写脚本，让它以一定的频率运行，并在它不为真的时候通知你。如果你不能期望master的tip commit出现在release，那么这个脚本就更复杂了。

我喜欢这样做，这样在列表视图中看起来就不会像master在develop之前。如果你把master合并到develop而不是release分支和hotfix，那么在列表视图中master永远不会在develop之前，如果是这样，你就知道出了问题，需要修复