GitFlow使用疑问：如何维护客户仍在使用的历史发行版本？

问题一：旧版本修复后需同步到trunk的操作流程 #

操作步骤如下：

• 找到待修复旧版本对应的发版tag（例如v2.1.0），执行命令git checkout -b support/v2.1.x v2.1.0创建该版本线的长期维护分支，support/[主版本号.次版本号.x]是通用命名规范，该分支专门承载对应版本线的所有更新
• 从support/v2.1.x分支拉取临时修复分支，命名建议为hotfix/[修复后小版本号-问题说明]，例如hotfix/v2.1.1-fix-data-acquisition-error，在该分支完成bug修复、自测、测试验证
• 将hotfix分支合并回support/v2.1.x分支，打完对应新版本tag（例如v2.1.1）后即可发布给对应使用旧版本的客户
• 如需同步到trunk，可执行git cherry-pick <hotfix提交ID>将修复内容同步到开发分支，后续随trunk的新版本发版即可。注意：如果trunk代码和旧版本差异过大，cherry-pick过程中需要手动解决冲突，建议修复旧版本时尽量和trunk的修复逻辑保持一致，降低冲突处理成本

问题二：旧版本修复无需同步到trunk的操作方案 #

完成上述前3步操作即可，不需要执行cherry-pick同步到trunk的步骤。support分支是独立的并行维护分支，不需要和trunk做合并操作，两个分支的tag、版本迭代完全独立，互不干扰。

GitFlow适配工业类产品的说明 #

你之前的认知存在偏差：GitFlow原生设计就包含support分支机制，专门适配To B、工业类需要多版本长期并行维护、客户不愿随意升级的场景，反而是高频发版的C端移动应用现在更多使用更轻量的Trunk Based Development流程。你觉得GitFlow不适配，只是因为常规的GitFlow入门资料很少提及support分支的用法，遗漏了这个核心的多版本维护设计。

内容的提问来源于stack exchange，提问作者Milan