版本控制与变更控制：区别在哪里
版本控制追踪的是一份文件当前是哪个版本、改了什么；变更控制决定的是一项拟议变更是否被允许发生，以及谁必须先批准它。
版本控制是识别并记住一份文件连续各状态的机制；变更控制是决定一次变更能否被允许、并在一个新版本被创建之前做出这个判断的治理流程。
简而言之
- 版本控制追踪的是身份和历史：这是哪个版本，它之前是什么样。
- 变更控制是治理：一项拟议变更是否被允许，谁必须批准它。
- 变更控制先运行：分类和批准是进入一个新版本的关口，而不是反过来。
- 一次小改和一次大改可以承受不同程度的变更控制，而版本控制的运作方式不会因此改变。
- 多数真实流程两者都需要，而且是叠加关系：变更控制做决定，版本控制做记忆。
两个不同的问题，共用一个对象
“这是哪个版本？”和“这次变更该不该发生？”是两个不同的问题，而大多数流程文档只回答了第一个。版本控制是一套贴标签加历史记录的机制：它给一份文件的每一个连续状态分配一个标识符，保留一条记录，写明它之前是什么样，并让你看清是谁在何时改了什么。它回答的是事后追责的问题。变更控制在它上游：这是决定一项拟议变更是否被允许、谁必须评审它，以及一个新版本被允许存在之前必须满足什么条件的治理流程。
下面这个文件变更控制工作流，把这条边界画成了一张图表，而不只是一句话。第 1 到第 8 行完全是变更控制：登记申请，把它分类为小改还是大改，把大改路由给一位评审人评估全面影响，一切都卡在一个“是否批准？”的判断上。这一切都没有碰到文件的版本。只有在通过批准关口之后，“更新版本号与分发名单”才会运行，在第 9 行——正是版本控制开始的确切位置。
QueryChart 用同样的方式把两者分开。对图表的每一次编辑，都会自动记入一份带逐字段差异的变更日志、一个比较版本视图，以及一键还原——这就是版本控制，不管有没有人要求，它都在运行，见 /features/version-control。而某次具体的编辑一开始是否被允许发生、谁签的字，则是像下面这样一张图表要回答的治理问题。想看范围更宽、更偏 IT/运营口味的那个版本的治理流程，而不是这个文件专属的版本，见 /zh/guides/如何创建变更控制流程。
变更控制在哪里结束，版本控制在哪里开始
一份文件的分类、评审与批准——然后是它的版本号真正发生变化的那一行。
一次申请，还没有版本变化
“识别到受控文件的变更”开启这张图表，然后是“提交文件变更申请”和“将申请登记到该文件的记录上”——三行全是变更控制，而这份文件的版本此时还没被动过。
分类和批准把关一切
“变更被归类为小改还是大改？”分流为一条快速通道的修改，或者一次完整评审——由变更评审人“评估全面影响”，并把它记录在相关文件与表单之上——然后才是“是否批准？”判断，而这一切都还没碰到版本号。
第 9 行是版本控制开始的地方
只有在变更获批之后，“更新版本号与分发名单”才会运行，随后是发布到受控位置、通知分发名单持有人、撤回被取代的副本——这是整个流程里属于版本控制的那一半。
驳回会循环回变更控制
答案“驳回”会把申请送去“修改草稿并重新提交评审”，回到变更评审人的影响评估——返工完全留在变更控制内部，直到“文件按正式变更控制重新发布”带着一个新版本合上这张图表。
运作方式
在你自己的流程里把这两个问题分开
在画任何东西之前，先决定什么属于变更控制（申请、分类、评审、批准），什么属于版本控制（标识符、修订号、历史、还原）。给这条边界命名，是大多数流程图会跳过的那个设计步骤。
先分类，再评估
在评估开始之前，先让每一个申请走过一个小改/大改的判断，就像第 4 行那样。一次措辞上的小修正和一次实质性的要求变更，不应该走同一条评审路径，提前决定哪个是哪个，能阻止每一次变更都被按最重的方式处理。
把版本控制这一步放在批准真正结束的地方
只有在通过批准关口之后，才递增版本号、设定生效日期、更新分发名单——绝不能提前。如果你的图表在这个判断之前就更新了版本，那你描述的就是一个连被驳回的草稿也会被版本化的流程。
给变更控制它自己的评审人，而不是文件负责人
一位评估全面影响、并把它记录在相关文件与表单之上的变更评审人，独立于提出这次变更的人，正是让“已批准”这三个字真正有意义的东西。在示例里，这一步位于分类和批准判断之间，而不是并入其中任何一个。
让版本控制在变更控制做完决定之后自己运转
一旦变更获批，发布、通知分发名单持有人和撤回被取代的副本都是机械性的工作——这是图表里属于版本控制的那条尾巴，也正是 QueryChart 的变更日志和比较版本视图已经替你处理好的那一半，见 /features/version-control。
应避免的错误
把“我们有版本历史”当成变更控制
一个给每次编辑打时间戳的工具，不是一套治理流程——它没有分类，没有评审人，也没有批准关口。版本历史回答的是改了什么；它对这次变更该不该发生这件事毫无意见。
在获批之前就给一次变更版本化
如果版本号在“是否批准？”判断之前就变了，一份被驳回的草稿依然会显示为一个新修订。把这次递增留在第 9 行，放在批准之后，就像示例做的那样。
所有变更都用同一个类别
让一次错字修正走和一次要求变更同样的评审，要么拖慢琐碎的编辑，要么让实质性的变更走上快速通道蒙混过关。第 4 行的小改/大改分流，正是为了让两者各自得到恰当程度的审视；关于怎么设计这些类别本身，见 /zh/guides/如何创建变更控制流程。
在你自己的图表里比较版本
这个示例的每一次编辑都已经被自动追踪——打开它，亲自查看变更日志和比较版本视图。
相关指南
常见问题
版本控制和变更控制是一回事吗？
不是。版本控制是识别并记住一份文件连续状态的机制——一个修订号、一份谁改了什么的历史，以及比较或还原到旧版本的能力。变更控制是决定一项拟议变更是否被允许发生、谁来评审、批准之前必须满足什么条件的治理流程。一份文件可以拥有严格的版本控制、却完全没有变更控制：每一次编辑都被保存，却没有人判断它该不该被做出来。
应该先搭建哪一个？
版本控制，因为它通常已经在你不知不觉中运转了：QueryChart 对每张图表都自动保留一份带逐字段差异的变更日志和一个比较版本视图，见 /features/version-control。变更控制是那个需要你主动设计的部分——类别、评审人、批准关口——这正是它值得像本文这样单独画成一张流程图的原因。
这和修订控制有什么不同？
实际上，“修订控制”和“版本控制”是同一套机制的两个不同叫法，都关注识别并追踪一份文件的连续状态。变更控制是不同的那一个：它管的是一次变更一开始是否被允许，通常以获批后产生一个新版本收尾。如果你要弄清楚的具体是修订控制和版本控制这两个词的问题，见 /zh/guides/修订控制与版本控制的区别。
文件控制在这两者之间处在什么位置？
文件控制是三者中范围最宽的：一份受控文件从申请到起草、评审、批准、发布，再到最终撤回或退役的完整生命周期。变更控制和版本控制都是它的一部分——变更控制治理单次拟议编辑，版本控制追踪那次编辑产生的标识符和历史。要看完整的生命周期，而不只是变更/版本这条边界，见 /zh/templates/文件变更控制流程 或范围更宽的 /zh/guides/如何创建文件控制流程。