我最近开始使用git开发一个开源项目，并决定根据Vincent Driessen的branching model工作。
我理解这个模型背后的原因，我已经看到它被广泛推荐，所以它似乎是一个不错的选择。
我在这个模型中缺少的，并且无法在线查找，这是在为旧版本（标记）创建修补程序的情况下推荐的方式。
例如，我的主人包含最新版本 - 2.0，我有版本1.5和1.0的标签。现在，假设正在使用1.0版的客户在该版本中发现了一个错误但不希望更新到包含错误修复的较新版本，而只是想要一个修补程序\补丁（不知道这里的正确术语是什么） 。根据该模型，不处理这种情况，并且在模型中，修复程序修复了修补程序分支，然后合并到主行（master \ dev）。但是在我的例子中，客户只需要最小的提交集来修复bug而没有新功能（尽可能多）。
在这种情况下，什么应该是最好的方法git-wise？我应该从标签1.0和cherry-pick提交创建专用分支吗？我应该从第一个修复问题的提交分支出来，如果更容易又回复吗？我应该永远保持这个分支吗？
我很想知道在以下情况下该怎么做：
欢迎参考不同分支模型的最佳实践。
答案 0 :(得分：0)
- 该错误已在更高版本中修复，例如介于1.5和2.0之间
如果开发遵循合理的流程（例如：逆向兼容性，增量扩展等），则用户的最佳解决方案是签出最新版本。
否则，如你所说，你应该考虑从标签1.0创建一个新分支的机会，挑选修补程序，然后将分支标记为subversion（1.0.1）。
您应该将相同的策略应用于下一个提交，或者至少应用于下一个标记：假设要在版本1.5中发布此修补程序，给定标记列表[1.0,1.2,1.3,1.5]您应该创建颠覆[1.0.1,1.2.1,1.3.1]。
- 这是一个新的错误，也应该合并为主。
通常从主分支的HEAD指向的提交开始应用此修补程序。
不推荐重写历史记录，因为您的项目将与其他人共享，同步点（推/拉）会有冲突。选择最合理的解决方案，但永远不要修补您与社区共享的提交。
答案 1 :(得分：0)
即便在版本1.0中发现此错误，但实际上它是新的。没有人能确定旧版本没有错误，所以对于新的查找错误，你应该在最新版本中修复它。因此，根据您的情况，您应根据2.0 修复错误。
因为master分支是托管在其上的主代码（或者我们称之为生产环境），所以您应该解决hotfixs分支上的错误，然后将其合并到{{1}分支。然后删除旧标记2.0，并为新的合并提交添加标记2.0。