版本控制与变更控制：区别在哪里
版本控制追踪的是一份文件当前是哪个版本、改了什么；变更控制决定的是一项拟议变更是否被允许发生，以及谁必须先批准它。
运作方式
在你自己的流程里把这两个问题分开
在画任何东西之前，先决定什么属于变更控制（申请、分类、评审、批准），什么属于版本控制（标识符、修订号、历史、还原）。给这条边界命名，是大多数流程图会跳过的那个设计步骤。
先分类，再评估
在评估开始之前，先让每一个申请走过一个小改/大改的判断，就像第 4 行那样。一次措辞上的小修正和一次实质性的要求变更，不应该走同一条评审路径，提前决定哪个是哪个，能阻止每一次变更都被按最重的方式处理。
把版本控制这一步放在批准真正结束的地方
只有在通过批准关口之后，才递增版本号、设定生效日期、更新分发名单——绝不能提前。如果你的图表在这个判断之前就更新了版本，那你描述的就是一个连被驳回的草稿也会被版本化的流程。
给变更控制它自己的评审人，而不是文件负责人
一位评估全面影响、并把它记录在相关文件与表单之上的变更评审人，独立于提出这次变更的人，正是让“已批准”这三个字真正有意义的东西。在示例里，这一步位于分类和批准判断之间，而不是并入其中任何一个。
让版本控制在变更控制做完决定之后自己运转
一旦变更获批，发布、通知分发名单持有人和撤回被取代的副本都是机械性的工作——这是图表里属于版本控制的那条尾巴，也正是 QueryChart 的变更日志和比较版本视图已经替你处理好的那一半，见 /features/version-control。
常见问题
版本控制和变更控制是一回事吗？
不是。版本控制是识别并记住一份文件连续状态的机制——一个修订号、一份谁改了什么的历史，以及比较或还原到旧版本的能力。变更控制是决定一项拟议变更是否被允许发生、谁来评审、批准之前必须满足什么条件的治理流程。一份文件可以拥有严格的版本控制、却完全没有变更控制：每一次编辑都被保存，却没有人判断它该不该被做出来。
应该先搭建哪一个？
版本控制，因为它通常已经在你不知不觉中运转了：QueryChart 对每张图表都自动保留一份带逐字段差异的变更日志和一个比较版本视图，见 /features/version-control。变更控制是那个需要你主动设计的部分——类别、评审人、批准关口——这正是它值得像本文这样单独画成一张流程图的原因。
这和修订控制有什么不同？
实际上，“修订控制”和“版本控制”是同一套机制的两个不同叫法，都关注识别并追踪一份文件的连续状态。变更控制是不同的那一个：它管的是一次变更一开始是否被允许，通常以获批后产生一个新版本收尾。如果你要弄清楚的具体是修订控制和版本控制这两个词的问题，见 /zh/guides/修订控制与版本控制的区别。
文件控制在这两者之间处在什么位置？
文件控制是三者中范围最宽的：一份受控文件从申请到起草、评审、批准、发布，再到最终撤回或退役的完整生命周期。变更控制和版本控制都是它的一部分——变更控制治理单次拟议编辑，版本控制追踪那次编辑产生的标识符和历史。要看完整的生命周期，而不只是变更/版本这条边界，见 /zh/templates/文件变更控制流程 或范围更宽的 /zh/guides/如何创建文件控制流程。