流程图版本控制究竟是怎么运作的
流程图版本控制到底是什么，为什么把图导出成 PDF 或 PNG 来“做版本”会丢掉它真正的结构，以及 QueryChart 的变更日志和比较版本如何自动追踪每一个方框、连线和标签的改动。
流程图版本控制记录的是一张图的方框、连线和标签的每一个历史状态——而不是装着它的那个文件——这样读者就能准确看到改了什么、谁改的，并能回退到任何一个更早的状态。
简而言之
- “v3_终版_已审(2)”这样的文件名是一种猜测，不是版本历史。
- PDF 或 PNG 导出保留的是流程图的一张图片，不是它可编辑的结构。
- 云存储的文件版本追踪的是文件，不是文件里面的方框和连线。
- 真正的流程图版本控制，能对任意两个已保存状态之间的方框、连线和标签改动做差异对比。
- QueryChart 的变更日志和比较版本，在每张图表上免费自动做到这一点——见 /features/version-control。
文件名不是修订历史
此刻共享盘上某处正躺着 流程地图_v3_终版_已审(2).vsdx，旁边是 流程地图_v3_终版_已审.vsdx，还有一份某位相关方至今还挂在旧邮件里的 流程地图_v2.pdf。这三者之间，没有任何记录说明哪个方框被挪动过、哪个判断分支改了标签、这两处改动分别是谁做的，也没人知道到底有没有人真正签字确认过——只有一个文件名在勉强顶替本该由版本历史承担的工作。
把流程图导出成图片或 PDF 用于存档，确实能保留它当时的样子，却丢掉了后来的读者真正需要的东西：底层可编辑的结构。一张 PNG 没法和另一张 PNG 做差异对比来显示某个判断框多了第三条分支——只能靠人盯着两张图猜。云盘自带的“版本历史”也解决不了这个问题：它给文件做版本，不是给文件里的图做版本。它能找回昨天的 .vsdx 或 .pptx，却不知道某个具体的方框换了泳道，也不知道某根连线的标签在两次快照之间从“升级”改成了“自动批准”。
一款真正带版本控制的绘图工具，能做到文件名和云盘做不到的三件事：让你浏览这张图本身的每一个历史修订版，准确显示任意两个版本之间哪个方框、哪根连线或哪个标签变了，并且在还原到旧状态时不会丢失之后做过的工作。QueryChart 在每张图表上、实时、自动、免费地做到这一点——变更日志记录每一次编辑，写明经办人和涉及的字段，比较版本把任意两个已保存版本并排展示。完整机制见 /features/version-control。
这个区别很重要，因为流程图和它可能被嵌入其中的那份流程文档，并不是同一个对象。本文说的是给流程图自身的结构——方框、泳道、连线——在一款专为追踪这种结构而生的工具里做版本控制。如果你要管理的其实是一份更长的、碰巧包含一张图的流程文档的修订，工具无关的那个版本见 /zh/guides/流程文档版本控制。
看这份文档如何逐行挣得自己的版本号
下面这套版本编号方案，正是一位文件负责人手工执行的那套纪律——草稿用小数，批准用整数——而这正是 QueryChart 的变更日志替这张图表本身自动追踪的同一个区分，不需要任何人手动打字输入编号。
草稿拿到的是小数，不是猜测
起点行是“新文件起草”，紧接着的下一行就是“分配初始草稿版本 0.1”——这个小数准确说明了草稿经过了多少轮评审，而这一切都发生在“将草稿分发给内部评审”和“评审人评估草稿”之前。
每一轮返工递增的是编号，不是猜测
在“是否需要修改？”这一步，答案“是”会先经过“递增小版本号”，再进入“根据意见修改草稿”，于是评审人说“对某个小数版本的意见”，指的是一份确切、可定位的草稿，而不是一份含糊的“最新版”文件。
只有批准这一件事能挣得整数
“提交最终草稿以供审批”和“审批人审查最终草稿”通向“是否批准发布？”——只有“批准”分支能到达“分配大版本号 1.0”，所以在此之前，无论经过多少轮小数草稿，都不会被误当成 1.0 版。
发布之前，登记册先更新
“更新版本历史登记册”在“发布已批准的版本”之前运行，“将前一版本标记为已作废”紧随其后——所以在任何读者到达“使用人员访问当前版本”之前，那份列出每一个历史编号、而不只是当前编号的登记册就已经是最新的。
之后的变更是重新开启记录，不是覆写它
“发布后是否有变更申请？”要么把流程送回“以下一个版本重新开启该文件”——重新启动这条编号链，而不是原地编辑当前文件——要么到达“当前版本继续生效”，此前每一个编号都仍留在记录上。
运作方式
别再把版本命名塞进文件里
彻底放弃“v3_终版_已审(2)”这套惯例——文件名里的小数或颜色标注是某个人自己加的标签，不是改动的记录。把流程图放进一款自带修订历史的工具里，让文件名重新回归它本来的作用：只是一个文件名。
让每一次提交评审都自动生成一个具名版本
在 QueryChart 里，把图表提交评审会自动保存一个具名版本，且从不覆写任何内容。这一个习惯，就取代了那一整套靠“另存为”产生的重复文件轨迹，因为无论有没有人记得改名，之前的状态都会被保留。
先打开变更日志，再去问改了什么
变更日志列出了对图表的每一次编辑、谁做的、大致什么时候——所以“周二以来改了什么”变成了滚动看一份列表，而不是靠记忆或对着两张导出的图片死盯着找。
用差异对比两个版本，而不是靠肉眼对比两份导出图
用比较版本选定任意两个已保存版本，逐字段查看差异——方框、连线和标签的改动会被单独标出为新增、删除或修改，而不用靠读者去两份摊平的 PDF 里自己找。
还原，而不是凭记忆重建
如果发现某个修订版本错了，还原到更早的版本，而不是照着一份旧的导出文件手工重画。还原本身会在历史里生成一条新记录，所以当前草稿的来龙去脉不会因此丢失。
把图表本身当作母本，导出文件只是快照
把你分发出去的 PDF 或 PNG 当作给读者看的快照，绝不要把它当成用来重建的那份记录——带版本历史的可编辑图表，才是唯一能回答“三月份的时候它长什么样”的那一份，导出文件做不到。
应避免的错误
文件名里的那个 (2) 就是破绽
在一个已经带版本号的文件名后面又加一个带括号的数字，说明有两个人同时编辑了同一份所谓的“最新”副本，而且没办法合并。真正的解法不是想出更好的命名规则，而是根本不需要命名规则——一张图表，一份历史，没有副本可以互相冲突。
导出的 PDF 比它来源的图表活得更久
贴在墙上或附在旧邮件里的 PDF，会在它导出所依据的那张图表早已更新之后，继续在外面流传，而 PDF 本身丝毫看不出这一点。把每一份导出文件都当作从创建那一刻起就标了日期，并且链接回那张实时的图表，而不是重新分享那个文件。
把文件版本控制和图表版本控制混为一谈
OneDrive、Google Drive 和 Dropbox 都能找回昨天的文件，但没有一个能告诉你某个判断框多了一条分支，或者某根连线的标签变了——它们给容器做版本，不是给里面的内容做版本。这种差异，只存在于绘图工具自己的历史里。
悄悄还原，而不是留下记录
把一份旧导出文件的内容粘贴回当前文件，会抹去“发生过一次还原”这个事实本身。像 QueryChart 那样，让还原生成自己的、带日期的新记录，能让下一位读者看到回滚的理由，而不是让这张图看起来一直就是这样。
创建你自己受版本控制的流程图
把版本编号示例打开成你自己的图表，提交一次评审，看着一个具名版本、变更日志和比较版本自动为它出现。
相关指南
常见问题
流程图版本控制和文件版本控制有什么不同？
原理上没有不同——两者都是保留某样东西的每一个历史状态，好让你看清改了什么、并能回退——但流程图的“改动”是结构性的：哪个方框挪动了，哪根连线被新增了，哪个标签被改写了。一套围绕文字和页码搭建的文件版本控制流程，没法给一个判断分支做差异对比。这个问题聚焦到一整份流程文档、而不是单张图的版本，见 /zh/guides/流程文档版本控制。
把流程图导出成 PDF 算是版本控制吗？
不算——那是一张快照，不是一段历史。PDF 捕捉的是某一个瞬间，没法自动和另一份 PDF 比较来显示改了什么，也没法被编辑回去，更不带任何关于上一次改动是谁做的、为什么改的记录。它适合用来给读者分享一份固定的副本；不能替代图表自身的版本历史。
QueryChart 里变更日志和比较版本有什么区别？
变更日志是时间线——每一次编辑、谁做的、大致什么时候，从上到下读。比较版本回答的是一个更窄的问题：选定任意两个已保存版本，看它们之间逐字段的差异，一个方框接一个方框、一根连线接一根连线地展示，而不用滚动整份日志自己去拼凑。
还原一张流程图的旧版本会丢失当前的工作吗？
不会——在 QueryChart 里还原一个旧版本会生成一个新版本，而不是删除它之后产生的那些版本，所以此后做过的工作仍留在历史里，只是不再是当前状态。还原这个动作本身没有任何破坏性。
