长期支持（LTS）分支是什么
为特定版本提供更长维护窗口：用 maint/x.y（或 release/x.y）分支承接安全修复与阻断级缺陷，并对外公开支持截止时间。核心流程是「先合主线、再回挑维护线」，保证下个正式版本不丢补丁。
基本信息
| 结构 | maint/x.y 维护分支加独立补丁标签 |
|---|---|
| 内容 | 安全修复与阻断类缺陷，功能改动不进维护线 |
| 策略 | 对外公开维护窗口与 EOL（停止支持）时间 |
| 流程 | 修复先进主线，再 cherry-pick 回维护线 |
| 发布节奏 | 按需或固定窗口发补丁版本（如 v1.2.7） |
| 验收 | 补丁版本跑回归测试后再发布，覆盖维护线独占的修复项 |
典型使用场景
- 安全公告响应：漏洞修复进入维护分支并快速发补丁版本。
- 长周期产品：客户停留在旧大版本，需要持续修复通道。
- 合规要求：公开支持时间表，满足采购与审计要求。
- 回挑管理：主线修完后按清单回挑，防止遗漏。
- 版本规划：提前宣布 EOL，给用户留升级窗口。
- 多线并行：同时维护两三个版本时，明确每条线的责任人与节奏。
- 发布公告：补丁版本发布后同步更新支持矩阵与升级指引。
维护操作示意
维护操作示意
git switch maint/1.2 # 切到维护分支（或先创建）
git cherry-pick <修复提交> # 从主线回挑已修复的提交
git tag -a v1.2.7 -m 'LTS patch 1.2.7' # 打补丁版本标签
git push origin maint/1.2 v1.2.7 # 推送分支与标签
git log --oneline main..maint/1.2 # 核对维护线多出的补丁维护线职责边界
| 变更类型 | 是否进维护线 | 示例 |
|---|---|---|
| 安全修复 | 进 | CVE 补丁 |
| 阻断级缺陷 | 进 | 崩溃或数据错误 |
| 普通功能 | 不进 | 新特性只在主线 |
| 文档更正 | 视情况 | 影响使用的错误说明 |
先合主线再回挑到维护线，保证下个正式版本不丢补丁；维护分支上用独立标签标记补丁版本，不要把修复直接打进旧的发布标签。