什么是文件、SOP 与流程的版本控制？
多数“什么是版本控制”的搜索结果默认说的是 Git 与源代码。本文把它定义为文件、SOP 与流程适用的版本控制，并与修订控制、变更控制、文件控制区分开来。
版本控制是指始终只保留一份当前、权威的文件、SOP 或流程版本，同时保留此前每一版的完整历史，并记录是谁改了什么。
简而言之
- 版本控制 = 一个当前版本 + 此前每一版的完整历史 + 谁改了什么的记录——文件和代码适用同一个道理。
- 修订控制是同一种做法的另一个名字；变更控制和文件控制是更宽泛的流程，把它当作其中一部分来用。
- QueryChart 已经为每张图表保留这份历史：变更日志、比较版本视图、一键还原——见 /features/version-control。
- 草稿的小版本号（0.1、0.2……）每轮评审都会推进；完整的大版本号只在正式批准时分配一次。
- 要给某个具体对象做版本控制？见 /zh/guides/如何对SOP进行版本控制、/zh/guides/如何对文件进行版本控制 或 /zh/guides/流程图版本控制。
只有一个当前版本，其余的都是历史
搜索“什么是版本控制”，几乎所有结果说的都是源代码管理——提交、分支、Git。本文说的是这个词更早、更朴素的用法：控制文件、标准作业程序和业务流程的版本，而不是代码。两者背后的道理并无不同：只有一个当前、权威的版本；此前每一版的完整历史；以及准确记录谁在何时改了什么。唯一不同的，是被版本化的对象——纸面工作，而不是代码库。
具体来说，这意味着对文件的每一次编辑都会产生一个新的、带编号的版本，而不是覆盖上一版，于是旧版本仍可查阅，而不是就此消失。在 QueryChart 中，这对你搭建的每一张图表都已经是现成的：变更日志记录了谁改了哪个字段、从什么值改成了什么值，比较版本视图把任意两个版本并排展示，还原一个旧版本只是单个动作，不必重新输入——完整介绍见 /features/version-control。这些都不需要另行开启，从图表创建的那一刻起就在每张图表上运行。
修订控制和版本控制是同一个概念的两种叫法——这两个术语在这个领域的大多数场合可以互换使用，你的组织偏好哪一个都无关紧要。变更控制和文件控制则是另一回事：它们是更宽泛的治理流程，把版本化当作其中一种机制来用，而不是它的同义词。变更控制流程（见 /zh/guides/如何创建变更控制流程）判断的是一项变更是否应该发生——影响、审批、回滚——而版本控制只是把已批准的结果之后怎么编号、怎么记录下来。文件控制流程（/zh/templates/文件控制流程，操作方法见 /zh/guides/如何创建文件控制流程）管的是一份文件的整个生命周期——起草、评审、批准、发布，并把被取代的副本从它存在过的每个地方撤回——版本控制只是其中的一个条款，不是它的全部。这三组对比各自有完整的独立对照页面：/zh/guides/版本控制与变更控制的区别、/zh/guides/版本控制与文件管理的区别 和 /zh/guides/修订控制与版本控制的区别；本文只需要你看清楚，它们不是同一件事的四种叫法。
如果你已经清楚自己要给哪种对象做版本控制，上面的通用答案就不如具体答案有用：标准作业程序见 /zh/guides/如何对SOP进行版本控制，一般受控文件见 /zh/guides/如何对文件进行版本控制，如果你要版本化的正是流程图本身，见 /zh/guides/流程图版本控制。下文的一切——浓缩定义、图表演示、操作步骤——都是这三者共同建立在其上的通用情形。
逐阶段看版本号是怎样被分配的
一份文件从小数版本的草稿，走过评审、批准和发布——准确看清它的版本号在哪里变化，在哪里不变。
草稿从 0.1 开始，不是 1.0
图表从“新文件起草”开始，直接进入“分配初始草稿版本 0.1”——用小数，因为在这套规则里，正式批准之前的任何版本都不会拿到整数。
评审回路推进的是小版本号
“将草稿分发给内部评审”和“评审人评估草稿”汇入“是否需要修改？”。答案为“是”会经过“递增小版本号”——0.1 变成 0.2——进入“根据意见修改草稿”，再沿着标为“重新评审”的分支循环，需要几轮就循环几轮。
整数版本号是挣来的，不是默认的
“提交最终草稿以供审批”和“审批人审查最终草稿”通向“是否批准发布？”。驳回会回到“递增小版本号”；批准则到达“分配大版本号 1.0”，以及记录这一步的文件形状行“更新版本历史登记册”。
发布的同一行，旧版本随即退役
“发布已批准的版本”之后紧跟着“将前一版本标记为已作废”，新版本一生效，旧版本就立刻退出使用。有人申请变更就重新进入“以下一个版本重新开启该文件”；其他所有人都到达“当前版本继续生效”。
运作方式
把某一个位置定为权威版本
其他任何副本——发出去的 PDF、打印件、存在共享盘上的一页——都只是那个位置的一份拷贝，不是第二个原件。如果两个地方都能自称是当前版本，无论你的编号看起来多规整，你都还没有真正的版本控制。
把草稿编号和正式发布编号分开
还在评审中的一律用小数，真正批准过的才用整数——就像上面示例图表里，0.1 到 0.3 一路走到 1.0。这样评审人说“0.3 版的意见”，指的是哪份草稿就毫无歧义。
记录谁改了什么，而不只是记录“有改动”
单独一个日期戳，并不能告诉读者到底动了什么。为每一次编辑记录经办人、字段以及改动前后的值——这正是 QueryChart 的变更日志在每张图表上自动做的事，不需要任何配置。
让两个版本可以比较，而不只是可以打开
能打开第 3 版、也能打开第 5 版，跟能看出两者之间改了什么，是两回事。QueryChart 的比较版本视图把任意两个版本并排展示，让差异直接呈现在你面前，而不用去猜。
把还原旧版本当作日常操作，而不是紧急事件
如果撤销一次错误编辑，需要找有数据库权限的人来介入，那你的版本控制就只停留在纸面上。还原旧版本应该是任何一位获得授权的编辑者，在发现问题的那一刻就能自己完成的动作。
应避免的错误
用文件名冒充版本号
“SOP_v2_FINAL_已审(1).docx”不是一套版本方案，只是一个碰巧带数字的文件名——没有任何机制保证这个数字只增不减，也没法阻止两个人各自做出自己的“FINAL”。版本号需要活在一个负责分配它的系统里，而不是活在某人保存前随手打的字里。
历史记录只留下了当前状态
原地覆盖一份文件，再把旧副本说成“存在什么地方了”，这不是版本历史，只是一种寄望。真正的历史让每一个旧版本都可查阅、可比较，而不只是靠还记得存放位置的人去找回来。
把“有版本号”当成“受控制”
文件上的一个数字只能说明它被版本化过一次；不能说明旧副本被撤下了，不能说明有人批准过这次变更，甚至不能说明这个数字真的和你以为的含义一致。版本控制是编号和日志——文件控制和变更控制才是管住这个过程本身的东西。
改换说法，却不改动做法
把组织的用词统一成“修订控制”而不是“版本控制”，或反过来，都不会改变变更是否真的被追踪这件事。它们是同一种做法的两个名字；真正值得花力气改的是日志本身，不是标签。
在 QueryChart 中查看图表的变更日志
QueryChart 里的每张图表都已经保留这份历史——创建一张，打开它的变更日志亲自看看。
相关指南
常见问题
版本控制和修订控制是一回事吗？
在实践中是的。两个术语描述的是同一个基本概念——一个当前版本，加上此前每一版的可查阅历史——不同的组织、工具和标准只是各自偏好其中一个词。用哪个术语都不会改变机制本身；完整对比见 /zh/guides/修订控制与版本控制的区别。
版本控制和变更控制有什么区别？
变更控制判断的是一项变更是否应该发生——它的影响、谁来批准、出问题该怎么回滚。版本控制记录的是这个决定落地之后的结果：新的编号、时间戳、经办人。变更控制流程可以在没有版本控制的情况下存在，只是做得不好；而没有变更控制的版本控制，只说明在编号之前没有人判断过这项变更是不是个好主意。CAB 和回滚机制见 /zh/guides/版本控制与变更控制的区别 和 /zh/guides/如何创建变更控制流程。
文件的版本控制和代码的版本控制原理一样吗？
核心思路完全一致——一个权威的当前版本、此前一切的完整历史、谁改了什么的记录——但具体机制不同。像 Git 这样的代码版本控制围绕分支和合并并行的工作线路搭建；而文件与流程的版本控制通常是线性的，一份草稿经过评审走到唯一一个被批准的版本，这更接近本文和上面示例图表所描述的情形。
QueryChart 的审计轨迹是默认开启的吗？
本文说的这套版本历史——变更日志、比较版本、还原——是免费功能，在每张图表上自动运行，无需设置。QueryChart 的合规审计轨迹，一种映射到 ISO 27001、SOC 2 和 HIPAA 控制项的哈希链记录，是一项单独的付费能力，需要组织主动开启。它不是默认开启的，也不是每个账号都已经在运行的东西。
