正在进行的发布过程中的热修复-合并还是樱桃-选择？

Question

我们正在尝试遵循SourceTree工具的git流和它的所有神奇按钮，如:开始/完成功能，开始/完成发布，开始/完成热修复。到目前为止，一切似乎都是合乎逻辑的。

小问题出现时，我们需要热修复，而我们有一个正在进行的发布分支。

因此，根据git流，一旦完成了热修复，热修复的分支就会被合并到主服务器和开发中--所以SourceTree就这样做了。在一个成功的git分支模型文档中，这是一种特殊情况，您需要将热修复分支合并到主服务器和发布分支中，稍后这个热修复将被合并回开发中。

我这里的问题是，我不想做这个手动合并来回，我仍然想使用魔术按钮从SourceTree工具。

那么我有什么选择：

1. 樱桃选择从开发到发布早午餐的热修复提交-不太喜欢它，因为历史是缺失的。
2. 将整个主分支合并到发布分支--甚至不确定这是否是个好主意

Answer 1

我意识到我的问题是什么。我们使用的流并不是纯的git流。根据git流，下一个版本在开发分支中，一旦它稳定并准备发布，就会创建一个短暂的(几分钟)发布分支，用于“点缀i's”。在此之后，这个分支就应该完成，把它合并成主分支，然后发展起来。因此，如果我们严格遵循git流，就永远不会出现“在当前发布分支中进行合并或选择”的问题，因为不会出现这样的情况。

Answer 2

考虑到关闭了修补程序分支(并且它被合并回develop和master)，如果您不想选择提交，我会考虑将develop分支合并到release分支中(首先看看自创建release分支以来develop上还发生了什么)。

如果您想要通过魔术按钮(没有命令行或手动合并)来完成这个任务，并且很乐意增加另一个版本号，那么您可以完成您的发行版(合并到主版，也可以合并到开发版，在您的修补程序完成后)，并启动一个新版本。