文件版本控制最佳实践
写给已经有一套编号方案的团队的文件版本控制最佳实践：保持它稳定，固定版本、日期和审批人出现的位置，杜绝对当前副本的并行编辑，并记录每一次“无需变更”的审查。
运作方式
一旦有真实文件依赖这套方案，就把它冻结
把对方案本身的改动——从整数改成语义化版本号，或者重新定义小数代表什么——当成一个项目来对待，而不是随手一改：它会让每一条已有的交叉引用、培训记录和历史审计引用全部失效。如果发现了缺陷，就把例外情况从此往后记录下来，而不是给整个库重新编号。
把版本、日期和审批人固定在每份模板上的同一个位置
选定一个位置——页眉或页脚——并把它内建进文件模板，让每一位作者不用另外做决定就沿用它。一个只存在于文件名或文件属性里的版本号，撑不过一次打印、一张截图或一次邮件转发；印在页面上的那个能。
给“当前”版本一套锁定或签出惯例
决定谁可以同时打开当前版本进行编辑，以及第二位作者怎么发现已经有人在编辑了——可以是登记册里的一个签出标记、一个被锁定的文件，或者一份唯一的、只有一次保存能生效的实时副本。没有这个，两次都获批的编辑落在同一个版本上，就不是一种假设情况。
在第一份文件用到大小版本规则之前先写下来
在定义编号方案的同一份文件里，明确规定到底是什么触发整数进位——单纯的正式批准，还是批准加上一次实质性重写。逐案判断的团队，最终会得到两份都叫 2.0 版的不同文件。
记录每一次定期审查，包括那些什么都没改的
给审查这一步一个带标签“无变更”出口的判断形状，让它也写入登记册的一条带日期条目，就像“发布后是否有变更申请？”到达“当前版本继续生效”而不是什么都不做那样。一条缺失的条目应该意味着审查没有发生，而不是意味着审查期间什么都没发生。
让一份唯一的实时副本彻底消除锁定问题
把文件放进一张 QueryChart 图表，而不是一堆靠邮件传来传去的文件，这样就只有一个当前版本可以编辑——每一次保存都会自动记入变更日志的一条新条目，签出惯例就没有什么可执行的了。见 /features/version-control。
常见问题
文件版本控制里最容易犯的一个大错是什么？
把方案当成只有在有人找到理由要改动它之前才算固定的东西。给一个已有的库重新编号——哪怕是为了修补一个真实存在的缺陷——都会让每一条引用了旧编号的交叉引用、培训记录和审计引用失效，而这个代价几乎总是超过容忍一套不完美方案的代价。用一条被记录下来的例外去从此往后修复问题，而不是去动已经发布的内容。
怎么阻止两个人同时编辑同一份“当前”版本？
要么加一套明确的签出惯例——登记册里的一个标记，显示谁正打开着这份文件，让第二位作者知道要等待——要么从结构上直接消除这种可能，只保留一份唯一的实时副本，而不是靠邮件或共享盘传来传去的一堆文件。QueryChart 走的是第二条路：每份文件都是一张实时图表，每一次保存都自动生成版本，没有第二份副本可以分叉。见 /features/version-control。
什么样的改动算大版本，什么样的算小版本？
没有一条放之四海而皆准的规则，这正是为什么它必须在第一份文件真正需要用到之前就写下来，而不是逐案判断。一个常见的惯例是把整数级的大版本进位单独绑定给正式批准——在此之间的每一次草稿修订，无论多实质，都保持小数——这样“这次改动有多大”就永远不用在分配版本号的那一刻现场争论。
一次没发现需要变更的定期审查，需要记录吗？
需要——一次没有被记录的审查，和一次从没发生过的审查没有区别。给你流程里的审查步骤一个带标签“无需变更”出口的判断形状，让它依然向登记册写入一条带日期的条目，就像图表的判断行会记录它走过的每一条分支，而不只是那些通向新内容的分支一样。