第3章 原型版本管理规范
3.1 适用场景
原型版本管理规范适用于以下场景：
- 多轮迭代交付：同一原型需经历多次评审、修改、验证，必须区分不同迭代版本。
- 多人协作开发：多个设计师/产品经理并行产出原型，需避免覆盖或混淆。
- 与上下游对齐：开发、测试、业务方引用原型时，需通过版本号准确定位。
- 历史回溯与审计：需要追溯某一轮评审时的原型状态，或对验收争议进行复核。
- 紧急修复与回退：线上原型出现问题时需快速回退到上一稳定版本。
3.2 前置条件
- 已确定原型工具的版本管理功能开启（如 Figma 版本历史 / Axure SVN 集成 / Git 仓库）。
- 团队已约定统一的版本号格式和分支命名模板（参见 3.3.1、3.3.3）。
- 项目成员具备对应工具的版本操作权限（创建分支、打标签、回退）。
- 已建立共享的变更记录表模板（参见 3.3.2）。
3.3 操作步骤
3.3.1 版本号命名规则
原型版本号采用 三段式 + 可选预发布后缀 的格式：
v<主版本号>.<次版本号>.<修订号>[-<预发布后缀>]
示例：
v1.0.0 —— 首个正式发布版本
v1.1.0 —— 新增功能，向下兼容
v1.1.1 —— 修复缺陷，无功能变更
v2.0.0-beta —— 重大架构调整，beta 预发布
v1.2.3-rc.1 —— 发布候选第 1 版| 段位 | 命名 | 触发条件 | 示例 |
|---|---|---|---|
| 主版本号 | MAJOR | 重大架构调整、不兼容 API 变更、整体交互重构 | v2.0.0 |
| 次版本号 | MINOR | 功能增删改、流程调整，向下兼容现有功能 | v1.3.0 |
| 修订号 | PATCH | Bug 修复、文案修正、性能优化，不改变功能 | v1.2.1 |
| 预发布后缀 | PRE-RELEASE | 内测（alpha）、公测（beta）、发布候选（rc） | v1.0.0-beta |
💡 最佳实践：原型未正式定稿前，始终使用 v0.x.x 作为主版本号（v0.1.0、v0.2.0…），首次对外交付时升为 v1.0.0。
3.3.2 变更记录表填写规范
每次版本发布前，必须在 变更记录表 中登记该版本所有变更内容。表格统一存放在项目 Wiki 或共享文档中。
| 版本号 | 日期 | 变更类型 | 变更说明 | 责任人 | 评审状态 |
|---|---|---|---|---|---|
| v0.2.0 | 2025-03-10 | 功能新增 | 新增“订单详情页”沉浸式预览 | 张三 | 已评审 |
| v0.2.1 | 2025-03-12 | Bug 修复 | 修复“支付流程”中金额显示溢位 | 李四 | 免评审 |
| v1.0.0 | 2025-03-20 | 重大发布 | 首版正式交付，含核心流程 6 条 | 王五 | 已评审 |
变更类型 说明：
- 功能新增——增加新页面、新交互流程。
- Bug 修复——纠正与设计稿不符或逻辑错误。
- 优化调整——交互细节、视觉样式、性能提升。
- 重大发布——主版本号升级，对应里程碑交付。
- 紧急修复——线上阻断问题，需走 hotfix 通道。
3.3.3 分支策略执行规范
基于 Git 工作流，原型管理使用以下四种分支类型：
| 分支名称 | 用途 | 生命周期 | 版本号示例 |
|---|---|---|---|
master |
始终保持可交付的稳定版本，仅允许从 release 或 hotfix 合并 |
常驻 | v1.0.0, v1.1.0 |
develop |
日常开发集成分支，所有 feature 分支合并至此 |
常驻 | v0.2.0, v0.3.0 |
feature/<功能名> |
单个功能或模块开发，从 develop 拉出，完成后合并回 develop |
短期（开发完成后删除） | — |
release/<版本号> |
发布前准备（回归测试、文案校对），从 develop 拉出，合并到 master 和 develop |
短期（发布后删除） | release/v1.0.0 |
hotfix/<版本号> |
线上紧急缺陷修复，从 master 拉出，合并回 master 和 develop |
短期（修复后删除） | hotfix/v1.0.1 |
⚠️ 禁止行为：不允许直接在
master 分支上提交原型修改；禁止将未评审的 feature 分支合并到 release 或 master。
3.3.4 归档与回退操作SOP
归档与回退操作必须按照标准化流程执行，避免数据丢失或版本混乱。
归档操作 SOP：
- 打标签：在
master分支上使用git tag创建版本标签。 - 推送标签：将标签推送至远程仓库。
- 归档记录：在变更记录表中锁定该版本行，标记为“已归档”。
- 存储产物：将原型源文件（.fig / .rp / .axure）备份至共享网盘或制品库。
回退操作 SOP：
- 确认回退版本：从变更记录表或 Git 标签列表确定目标回退版本。
- 创建回退分支：基于目标版本标签创建回退分支
revert/<版本号>。 - 执行回退：在
master分支上使用git revert或git reset回退到目标版本。 - 更新版本号：回退后修订号 +1，并添加后缀
-revert标识（如 v1.0.2-revert）。 - 记录回退原因：在变更记录表中增加一条“紧急回退”记录，注明回退原因和决策人。
- 通知关联方：同步邮件或企微消息通知开发、测试、产品团队。
常用命令示例：
# 创建标签
git tag -a v1.0.0 -m "原型正式版 v1.0.0"
git push origin v1.0.0
# 回退到指定版本
git checkout master
git log --oneline -5
git revert HEAD --no-edit # 撤销最新一次提交（安全回退）
# 或
git reset --hard v0.9.0 # 强制回退（谨慎使用，需团队确认）
git push origin master --force-with-lease
⚠️ 回退红线：禁止在未通知全组的情况下使用
git reset --hard 强制回退；必须先在变更记录表中创建“回退”条目并获得技术负责人审批。
3.4 输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 版本号管理 | 当前版本号、变更需求清单 | 新版本号、版本号变更公告 |
| 变更记录 | 变更内容描述、评审结论 | 已填写的变更记录表（最新行） |
| 分支操作 | 待合并的原型分支代码 | 合并后的 master / develop 分支、已删除的临时分支 |
| 归档操作 | 待发布的原型源文件、标签列表 | 已归档的版本标签、制品备份链接 |
| 回退操作 | 回退目标版本号、回退原因说明 | 回退后的 master 分支、变更记录表回退条目 |
3.5 责任边界
| 角色 | 职责 | 批准权限 |
|---|---|---|
| 产品经理 | 提出版本号变更需求、审核变更记录表、确认归档版本 | 审批版本号升级（MAJOR / MINOR） |
| 设计师 | 执行版本号命名、填写变更记录、创建分支、提交合并、打标签 | 审批 PATCH 级别变更 |
| 技术负责人 | 审核回退请求、监督分支策略执行、处理异常冲突 | 审批回退操作、审批 hotfix 分支合并 |
| 配置管理员 | 维护分支权限、定期清理过期分支、审计版本记录完整性 | 审批分支删除、归档状态锁定 |
3.6 记录材料
- 变更记录表（共享文档 / Confluence / Wiki）—— 每次版本变更必须登记。
- 分支操作日志（Git 提交历史）—— 保留所有合并、回退、标签创建记录。
- 归档清单（制品库 / 网盘目录）—— 记录每个归档版本的文件路径和校验值。
- 回退审批单（企微 / 邮件审批）—— 紧急回退时需留存审批截图。
3.7 异常处理
| 异常场景 | 处理方式 | 责任人 |
|---|---|---|
| 版本号冲突（多人同时提交同一版本） | 以 Git 提交时间戳为准，后提交者重新定义次版本号（+1）并更新变更记录 | 设计师 |
| 变更记录表遗漏条目 | 在发现后 2 小时内补录，并标记“补录”注明原因；每周五做一次全量审计 | 产品经理 |
| 分支误合并（如 feature 直接合并到 master） | 立即执行 git revert 撤销合并，通知技术负责人复核，并在变更记录表中登记 |
技术负责人 |
| 回退后发现新问题 | 停止回退分支，基于原 hotfix 流程重新修复，版本号在回退版本基础上修订号 +1 |
设计师 + 技术负责人 |
| 归档文件损坏或丢失 | 从 Git 标签重新导出原型源文件，校验完整性后重新归档 | 配置管理员 |
3.8 验收标准
- ✅ 所有原型版本均采用
vMAJOR.MINOR.PATCH格式命名，无手工随意编号。 - ✅ 变更记录表每个版本一行，必填字段（版本号、日期、变更类型、责任人、评审状态）完整无空值。
- ✅ master 分支始终保持可交付状态，每次合并后自动打标签。
- ✅ 临时分支（feature / release / hotfix）在合并后 3 个工作日内删除，无残留。
- ✅ 回退操作有审批记录，回退后版本号清晰标识
-revert后缀。 - ✅ 归档版本源文件已上传至制品库，路径与版本号一一对应。
- ✅ 全组成员可通过变更记录表快速定位任意历史版本及其变更内容。