3. 版本分支管理策略：命名与生命周期

适用场景

本策略适用于采用Git进行版本控制的OTA固件开发项目，旨在为团队提供一套标准化的分支命名规范与生命周期管理方法。适用于以下场景：

• 多个开发人员并行开发多个功能模块
• 需要同时维护多个已发布的固件版本（如V1.0、V1.1）
• 线上出现紧急安全漏洞或严重崩溃，需要立即修复并发布热更新
• 需要隔离未完成的功能，确保发布分支的稳定性

前置条件

• 已建立并初始化远程Git仓库（如GitLab、GitHub、Gitee）
• 开发团队已完成基础的Git操作培训
• 已确定固件版本号规范（如语义化版本 2.0.0）
• 项目已启用分支保护规则（保护主分支、发布分支不受直接推送）

操作步骤

1. 定义主干与开发分支
   • 确认 master（或 main）分支作为主分支，始终保持与线上生产环境完全一致的代码状态。
   • 从 master 分支拉出 develop 分支，作为日常集成开发的主线。
2. 创建功能分支
   • 从 develop 分支创建功能分支，命名格式：feature/<功能简述>，例如 feature/ble-pairing。
   • 功能开发完成后，发起Pull Request (PR) 合并回 develop 分支。
3. 创建发布分支
   • 当 develop 分支累积了足够的下一次发布功能，且经测试达到发布标准时，从 develop 分支创建发布分支。
   • 命名格式：release/<版本号>，例如 release/v2.1.0。
   • 在发布分支上只进行缺陷修复、版本号更新、发布说明编写，不允许新增功能。
   • 发布分支稳定后，合并至 master 并打上对应版本的Tag，同时合并回 develop 分支以同步修复内容。
4. 创建热修复分支
   • 当线上已发布版本（master分支的某个Tag）出现需要立即修复的严重问题时，从对应的Tag或 master 分支创建热修复分支。
   • 命名格式：hotfix/<版本号-补丁描述>，例如 hotfix/v2.0.1-ota-auth-fix。
   • 修复完成后，合并至 master 并打上补丁版本Tag，同时合并至 develop 分支以确保后续版本包含该修复。
5. 清理与归档
   • 功能分支、发布分支、热修复分支在合并完成后，需及时从远程仓库删除。
   • 保留所有Tag（如v2.0.0, v2.1.0, v2.0.1）作为历史发布记录。

输入输出物

角色	输入物	输出物
架构师/技术负责人	项目版本规划、迭代计划	分支策略规范文档、分支保护规则配置
开发工程师	功能需求、缺陷单	功能分支代码、Pull Request
发布经理	测试通过报告、发布Checklist	发布分支、发布Tag、发布说明
运维/集成工程师	线上事故报告、安全通告	热修复分支、补丁Tag、修复后的构建产物

责任边界

记录材料

在分支生命周期管理中，需要维护以下记录：

项目仓库：/repos/ota-firmware
采用的分支模型：git-flow 扩展版
分支命名规则：
  - 主分支：master
  - 开发分支：develop
  - 功能分支：feature/<jira-id->-<功能描述>
  - 发布分支：release/v<主版本>.<次版本>.<修订版本>
  - 热修复分支：hotfix/v<修订版本>-<修复简述>

需要定期维护的列表（建议以仓库Wiki或README形式维护）：
  - 当前活跃的版本分支列表（release/*）
  - 最近3个发布版本的Tag记录
  - 尚未合并回develop的热修复分支说明

异常处理

验收标准

• 命名合规： 仓库中当前所有活跃分支的命名均符合本策略中定义的格式（master / develop / feature/* / release/* / hotfix/*）。
• 生命周期清晰： 功能分支在合并后已从远程删除；发布分支在创建Tag后已从远程删除；热修复分支在合并到master和develop后已从远程删除。
• 保护策略生效： master 和 release/* 分支禁止直接推送，所有变更必须通过Pull Request并经过至少1人审核。
• CI/CD联动正常： 针对不同分支模式（feature、develop、release、hotfix、master）的CI/CD流水线规则均已配置并触发正确。