据我了解，GIT工作流的描述方式如下： http ://nvie.com/posts/a-successful-git-branching-model/
我有一个与此工作流程中的旧分支机构错误修正有关的问题。
鉴于我们有许多较旧的发行分支合并到master分支中。 我们的最新版本是2.6。 我们需要修复一些在旧版本分支中发现的错误，例如1.5。 我们从与版本1.5相关的主分支状态创建一个分支，对其进行修复，部署和确定。 但是现在仍然存在一个问题：我们如何存储和传播此更改到所有较新的版本？
我们不能只是将此修补程序合并到母版中。 例如，由于我们要修复的类可能会在版本2.3中删除。 master分支的HEAD中可能没有它。
不确定我们是否可以将其合并到大师的历史中。 我无法想象它应该如何更改所有提交。
因此，看起来像在此修补程序之后，master分支的所有下一个提交都已过期并且无法使用。 而且，如果我们在1.9版本中存在一些错误，那么我们唯一的选择是从1.9提交，从master提交分支，以某种方式将其与1.5修补程序合并，然后继续。
我的理解正确吗？
提到的工作流程不包括您提到的情况。 如果旧的类在更新的版本中不存在，则意味着该错误可能甚至也不存在，因此不应将错误修正传播到该新版本。 同样，您也不需要将其合并到母版历史记录中，因为母版可以表示当前产品状态（由客户掌握），这在发行版中处于领先地位。 请记住，更改任何旧节点的历史记录将更改下一个节点的所有历史记录链。
要解决此问题，最好创建一个新分支，例如称为“ Support-1.5”，其中包含与该产品特定特定版本的支持有关的更新，将您的相关错误修正合并到该分支中，并且此支持分支有效只要支持该产品的旧版本即可。
希望这可以帮助。