第4章 原型版本管理规范

适用场景

原型版本管理规范适用于以下关键节点：

• 多轮迭代交付——原型在评审前经历多次修改，需清晰标识每次变更的版本基线。
• 多人协作设计——多个设计师同时提交不同方案的 PR（Pull Request），需要统一分支命名和合并策略。
• 评审回溯与追责——评审会中发现严重问题，需快速回退到上一个稳定版本并记录责任方。
• 合规审计——客户或内部质量部门要求提供完整的版本变更历史与审批签字记录。

前置条件

• 已搭建好 Git 仓库（GitHub / GitLab / Bitbucket），并赋予团队相应权限。
• 设计师已安装 Git 客户端或支持 Git 的协作工具（如 Abstract / Figma 版本历史插件）。
• 团队已约定统一的版本号规则（语义化版本或简化版本），并写入项目 README。
• 项目管理员已创建好 main、develop 以及 release/ 前缀的基准分支。

操作步骤

步骤1：版本号规则

原型版本采用语义化版本号（Semantic Versioning）的简化子集，格式为 MAJOR.MINOR.PATCH。每次评审会前必须冻结版本号，禁止在评审期间修改。

步骤2：分支命名

所有原型设计文件必须基于 develop 分支创建功能分支，命名格式如下：

步骤3：更新日志

每次提交或合并时，必须按以下模板记录 CHANGELOG.md：

# 原型更新日志

## [v2.1.0] - 2026-03-20

### 新增
- 用户个人中心页面（PRD-88）
- 夜间模式切换开关

### 修改
- 首页卡片布局由 4 列调整为 3 列（评审反馈 #23）
- 按钮圆角从 4px 改为 8px

### 修复
- iOS 设备上列表滚动卡顿问题
- 空状态文案显示不全

### 废弃
- 旧版引导页（将随 v3.0 移除）

每个版本必须包含：标题、日期、版本号、变更类型（新增/修改/修复/废弃）以及详细描述。推荐关联需求编号或评审反馈编号。

步骤4：审批记录表

每次评审会结束后，必须填写《原型版本审批记录表》，作为版本可追溯的书面证据。表格格式如下：

步骤5：回退机制

当评审会发现问题需要回退时，按以下优先级执行：

1. 基线标签回退——如果版本已打 tag（如 v2.1.0），直接 git checkout v2.1.0 并基于该 tag 创建修复分支。
2. git revert——如果问题仅涉及最近 1~2 次提交，使用 git revert <commit-hash> 生成一个反向提交，保留历史。
3. git reset——仅限本地或未推送的分支使用，严禁对已推送的 main / release 分支执行 git reset --hard。

# 推荐回退流程（安全操作）
git checkout release/v2.1.0
git log --oneline -5                  # 确认要回退的提交
git revert HEAD~2..HEAD              # 回退最近 2 个提交
git commit -m "revert: 回退 v2.1.0 中的样式修改（评审问题 #34）"
git push origin release/v2.1.0

输入输出物

责任边界

• 设计负责人：保证分支命名和版本号规则在团队内落地，检查 CHANGELOG 是否完整。
• 技术负责人：维护 Git 仓库分支权限，执行或审核回退操作。
• 产品经理：在评审会上确认版本号是否正确，并在审批记录表上签字。
• 质量工程师：审计版本管理流程是否合规，抽查审批记录表与 CHANGELOG 的一致性。

记录材料

每次评审会结束后需归档以下材料至项目 docs/releases/ 目录：

• CHANGELOG.md —— 最新版本的历史变更记录。
• approval-record-v{版本号}.pdf —— 当前版本的审批记录表扫描件。
• release-notes-v{版本号}.md —— 面向客户的发布说明（可选）。

异常处理

验收标准

满足以下所有条件，方可认为版本管理规范已落地执行：

• ✅ 仓库中可查到 VERSION 或 README 中显式声明了版本号规则。
• ✅ 所有功能分支均按 feature/<ID>-<描述> 格式命名，无脏分支。
• ✅ CHANGELOG.md 包含最近 3 个版本的完整记录，且格式与模板一致。
• ✅ 本次评审对应的审批记录表已签字归档，版本号与 CHANGELOG 一致。
• ✅ 回退操作有对应的 Git 提交记录和 CHANGELOG 条目，且未破坏 main 分支历史。