问Git-flow:当有未来的版本时，如何创建一个修补程序版本？

EN

您不希望在master上将这些提交插入到1.2和1.3的提交和标记之间。尽管你可以重新定位，引入这样的提交是重写历史的一种形式，并且可能会给在本地使用分支的其他人带来问题。

这暴露了git流模型中的一个缺陷。

git-flow模型的一个说明用例是“您需要在野外支持多个版本的软件”。要做到这一点，而不重写历史，您需要有长期存在的发行分支。在发行版不再受支持之前，您无法删除发布分支，因为将提交和标记注入master分支所需的任何技术都可能会导致严重的问题。

由于解决方案是在发行版不再受支持之前保持发布分支，我的建议是为所有受支持的主要和次要版本提供发布分支。也就是说，您将保留release-1.2、release-1.3、release-1.4和release-2.0分支，但永远不会保留release-1.2.1或release-1.4.3分支。

因为您的发布分支现在寿命很长，所以可以在发布分支上创建您的修补程序分支，而不是标记。您可以开发修复程序，测试它，然后将其合并到发布分支中。在这里，您可以构建和部署系统。

如果在多个发行版分支(包括下一个版本的develop中)需要进行相同的更改，则可以选择提交。但是，如果所需的更改是不同的，这并不总是可能的。当您有多个受支持的版本时，您可能需要多次进行修复并发布不同的修补版本，以便在每个受支持的版本中进行正确的更改。这取决于您正在修复的问题的性质以及修复问题所需的更改。

作为保持发布分支的替代方法(如托马斯·欧文斯的回答中所描述的那样)，一些人用长寿命的support分支扩展了git流模型。

当需要该版本上的第一个修补程序时，将从1.2发行版的标记中创建一个support分支，并将收集1.2版本上的所有修补程序和相关的发布标记。