问题描述
我的问题围绕gitflow流程中的一个非常特定的点(如此处).
我已经将错误修复从release/1.2合并到master，并进行了适当的标记.
除了历史记录外，release/1.2的反向合并与master的反向合并到develop之间的区别是什么.
我已经尝试了两种方法，在我的简单，人为的示例中，我没有想到develop有所不同.
这有危险吗?以后我会遇到麻烦的问题吗?我缺少明显的东西吗?我怀疑答案可能与master中已加入的其他功能有关，但暂时应保留在develop中.
合并发行版以进行开发:
合并母版进行开发:
如果将master合并回您的开发中，则在合并release/x.y时，您将在自己的开发分支中拥有所有merge branch release/x.y into master合并提交.分支本身，您只会得到真正的改变.
当然，这或多或少是一个装饰性的问题.但是合并方向通常仅是从develop到master，而不是相反.
除了所说的合并提交使您的develop分支杂乱无章之外，没有真正的危险.如果您坚持不懈，那么master中就永远不会有develop中没有的功能，因为热修复程序和发行版分支应该始终合并到develop和master中. /p>
My question is around a very specific point in the gitflow process (as documented here).
I've already merged bugfixes from release/1.2 into master, and tagged appropriately.
Apart from how the history looks, what are differences between back-merging from release/1.2 vs back-merging from master into develop.
I have tried both ways, and in my simple, contrived example I see no difference in develop, as I expected.
Are there dangers to this? Am I going to encounter messy issues later on? Am I missing something obvious? I suspect the answer may be to do with other features that have gone into master, but which should remain out of develop for the moment.
merging release in to develop:
merging master in to develop:
If you merge master back into your develop, you will have all the merge branch release/x.y into master merge commits in your develop branch, while when merging the release/x.y branch itself, you only get the real changes.
Of course, this is more or less a cosmetic issue. But the merge direction is usually only from develop to master, never the other way around.
There are no real dangers except for said merge commits cluttering up your develop branch. If you stick to the flow, there should never be features in master that are not in develop, since hot fixes as well as release branches should always be merged into your develop as well as in master.
这篇关于Gitflow:将发行版的错误修正合并回母版进行开发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！