旧标签中git修补程序的最佳实践

Question

最近，我开始使用git开发一个开源项目，并决定根据文森特·德里森的分支模型进行工作。

我理解这个模型背后的原因，并且我看到它被广泛推荐，所以它似乎是一个很好的选择。

我在这个模型中所缺少的，也没有在网上找到的，是在为旧版本(标记)创建修补程序的情况下推荐的方法。

例如，我的主人包含最新版本- 2.0，我有1.5和1.0版本的标记。现在，假设正在使用1.0版本的客户在该版本中发现了一个bug，但不希望更新到包含bug修复的更新版本，而只是想要一个hotfix\修补程序(不确定这里的正确术语是什么)。根据模型，这种情况不会被处理，在模型中，一个热修复被固定在一个热修复分支上，然后合并到主线(master\dev)。但是在我的示例中，客户只需要最小的提交集，它可以修复bug，而不需要新的特性(尽可能多)。

在这种情况下，什么才是最好的方法？我应该从标签1.0和樱桃提交创建一个专门的分支吗？我是否应该从修复问题的第一次提交开始分支，如果更容易的话应该返回吗？我应该让这支树枝永远活下去吗？

我想知道该怎么做以防：

1. 这个bug在以后的版本中已经修复了，例如在1.5到2.0之间。
2. 这是一个新的错误，也应该合并到主。

欢迎引用具有不同分支模型的最佳实践。

Answer 1

1. 这个bug在以后的版本中已经修复了，例如在1.5到2.0之间。

如果开发遵循合理的流程(例如:追溯兼容性、增量扩展等)对用户来说最好的解决方案是签出最新版本。

否则，正如您所说的，您应该考虑从标签1.0创建一个新分支的机会，选择修补程序，然后将分支标记为subversion (1.0.1)。

您应该将相同的策略应用于下一个提交，或者至少应用于下一个标记:假设给定标签列表1.0、1.2、1.3、1.5，您应该创建subversions 1.0.1、1.2.1、1.3.1，然后在1.5版本中发布修补程序。

1. 这是一个新的错误，也应该合并到主。

修补程序通常从主分支的头指定的提交开始应用。

不建议重写历史记录，因为您的项目将与其他人共享，并且在同步点(推/拉)上会出现冲突。选择最合理的解决方案，但不要修补与社区共享的提交。

Answer 2

甚至在1.0版中也发现了这个bug，但实际上它是新的。没有人能确定旧版本没有bug，所以对于新的查找错误，您应该在最新版本中修复它。因此，对于您的情况，您应该基于2.0修复这个错误。

因为master分支是托管在master上的主要代码(或者我们称之为生产环境)，所以您应该解决hotfixs分支上的错误，然后将其合并到分支中。然后删除旧的标签2.0，并为新的合并提交添加标记2.0。