个人项目如何设计回滚记录

个人项目最容易忽略的不是“如何回滚”，而是“回滚时依据什么判断”。如果版本号只负责递增，却没有记录每次发布改变了什么、依赖什么、出现过什么问题，那么出故障后即使保留了旧文件，也很难确认应该退回哪个版本。

回滚记录应回答四个问题

一条合格的记录，至少要让维护者快速确认：

• 当前版本是什么，上一版可用版本是什么；
• 本次发布新增了哪些功能，修复了哪些问题；
• 是否改变了数据、配置或核心使用方式；
• 出现异常时，回滚会丢失哪些变化。

版本号应保持固定含义。例如使用 A.B.C 时，主版本号表示重大变化或不兼容变化，次版本号表示新增功能，修订号表示问题修复。若使用 A.B.C.D，第四段只能统一表示构建号或日期号，不能今天表示构建次数，下一次又临时改成日期。阶段标识也要单独记录：Alpha 说明功能仍在形成，Beta 说明功能基本完整但仍在测试，RC 则表示接近正式发布。

不要只记录“退回到哪个版本”

每次发布都应保留一条简短的变更记录，例如：

版本：1.1.0
状态：正式版
上一可用版本：1.0.1
新增：周期记录功能
风险：已有记录格式可能受到影响
回滚条件：核心记录无法正常读取
回滚结果：退回 1.0.1，新增功能暂不可用

其中“上一可用版本”比单纯的版本号更重要。版本历史应明确区分正式版、测试版和候选版本，不能把 1.0.0-beta 与 1.0.0 当作同一状态。若新版本问题只影响新增功能，可以先暂停发布；若核心数据或原有用法受到破坏，则应优先恢复上一个可用版本。

把数据变化单独写清楚

代码回滚不一定等于数据回滚。新增功能可能改变数据结构、配置内容或使用流程，因此发布记录必须标明这些变化是否可逆。若无法确认，不能把版本号当作安全保证，而应保留旧版本和对应记录，先验证回滚后的数据能否正常使用。

个人项目不需要复杂的发布系统，但必须形成稳定习惯：每次发布前记录变化、风险和上一可用版本；发布后补充结果；发生回滚时记下触发原因与实际退回版本。这样，版本号负责定位，变更记录负责解释，回滚记录负责还原决策过程。