流程圖版本控制：實際運作方式
流程圖版本控制是甚麼、把圖表匯出成 PDF 或 PNG 來「做版本」為何丟棄了真正的結構，以及 QueryChart 的變更日誌與比較版本如何自動追蹤每一個方框、連線與標籤的變動。
流程圖版本控制，記錄的是圖表裡方框、連線與標籤每一個過去的狀態——不是承載它的那個檔案——令讀者能夠準確看到改了甚麼、誰改的，並且退回任何較早的狀態。
簡而言之
- 像「v3_FINAL_reviewed(2)」這樣的檔案名稱，是一個猜測，不是版本歷史。
- 匯出成 PDF 或 PNG，保留的是流程圖的一張圖片，不是它可編輯的結構。
- 雲端儲存的檔案版本，追蹤的是檔案本身，不是檔案裡的方框與連線。
- 真正的流程圖版本控制，會為任何兩個已儲存狀態之間的方框、連線與標籤改動做差異比對。
- QueryChart 的變更日誌與比較版本，會為每一張圖表自動做到這一點，而且免費——見 /features/version-control。
檔案名稱不是修訂歷史
此刻，共用磁碟的某個角落，正躺着一個叫 Process_Map_v3_FINAL_reviewed(2).vsdx 的檔案，旁邊是 Process_Map_v3_FINAL_reviewed.vsdx，還有一份 Process_Map_v2.pdf，仍然附在某位持份者的舊電郵串上。這三者之間，沒有任何紀錄告訴你哪一個方框搬動過、哪一條決策分支改了標籤、是誰做的其中哪一次改動，或者有沒有人真的簽署核准過——只有一個檔案名稱，在做本應由版本歷史負責的工作。
把流程圖匯出成圖片或 PDF 作存檔，確實留住了它當時的樣子，卻丟棄了日後讀者最需要的東西：底下那個可編輯的結構。一張 PNG 沒辦法跟另一張 PNG 做差異比對，去顯示一個決策方框多了第三條分支——只能靠人肉眼看着兩張圖片猜。雲端硬碟自己的「版本歷史」也解決不了這個問題：它為檔案做版本，不是為檔案裡的圖表做版本。它可以交回昨天那個 .vsdx 或 .pptx，卻完全不知道某個方框在兩張快照之間換了泳道，或者某條連線的標籤由「呈報」改成「自動批准」。
一個具備真正版本控制的繪圖工具，能做到檔案名稱與共用磁碟做不到的三件事：讓你瀏覽圖表本身每一個過去的修訂、準確顯示任何兩個修訂之間哪一個方框、連線或標籤改動過，並且在不失去其後所做工作的情況下，還原一個舊狀態。QueryChart 為每一張圖表即時、自動、免費做到這一點——變更日誌記錄每一次修改，連同是誰做的、改了哪個欄位；比較版本則把任何兩個已儲存的版本並排顯示。完整機制見 /features/version-control。
這個分別很重要，因為一張流程圖，跟它可能嵌入其中的那份較長流程文件，不是同一個對象。本頁講的是在一個以追蹤結構為本的工具裡，為圖表本身的結構——方框、泳道、連線——做版本控制。如果你要管理的，反而是一份剛好含有一張圖表的較長流程文件的修訂，這個問題與工具無關的版本，見 /yue/guides/流程文件與流程圖的版本控制。
這份文件如何逐列掙得自己的版本號
下面的版本編號方案，正正就是一位文件負責人手動執行的那套紀律——草稿用小數、審批用整數——而 QueryChart 的變更日誌為圖表本身自動追蹤的，正是同一個分別，不需要任何人打入一個編號。
草稿掙得的是一個小數，不是一個猜測
起點列是「新文件已開始草擬」，緊接的下一列就是「訂定初始草稿版本 0.1」——這個小數準確標示了草稿經歷過多少次審閱循環，甚至在「把草稿分發作內部審閱」與「審閱人評估草稿」發生之前就已存在。
每一次返工遞增的是編號，不是猜測
在「是否需要修改？」，答「是」會先經「遞增小數版本」，然後才開始「按意見修改草稿」，所以審閱人談及某個具體小數版本的意見時，指名的是一份確切、可定位的草稿，而不是一個含糊的「最新」檔案。
審批是唯一掙得整數的事件
「提交定稿作審批」與「審批人審閱定稿」帶到「是否批准發放？」——只有「批准」分支到達「訂定整數版本 1.0」，所以無論之前經歷過多少個小數草稿，在這一點之前的任何東西，都不會被誤認成版本 1.0。
發布之前先更新登記冊
「更新版本歷史登記冊」在「發布已批准的版本」之前執行，緊接其後就是「把上一版本標示為作廢」——於是，在任何讀者到達「讀者存取現行版本」之前，那份列出每一個舊編號、不只是現行編號的登記冊，就已經是最新的。
日後的變更是重開紀錄，不是覆蓋它
「發布後是否有變更要求？」要麼把流程送回「以下一個版本重新開啟文件」——重新啟動整條編號鏈，而不是原地修改現行檔案——要麼在「現行版本維持生效」結束，每一個舊編號仍然留在紀錄上。
運作方式
停止在檔案名稱裡命名版本
徹底淘汰「v3_FINAL_reviewed(2)」這套慣例——打進檔案名稱裡的一個小數或一種顏色，只是某人加上去的標籤，不是改動的紀錄。改為在一個自備修訂歷史的工具裡建立流程圖，讓檔案名稱回歸單純的檔案名稱。
為每一次提交審閱，配一個具名版本
在 QueryChart 裡，提交一張圖表作審閱，會自動保存一個具名版本，沒有任何內容會被覆蓋。單是這一個習慣，就取代了整條「另存新檔」留下的重複檔案痕跡，因為之前的狀態會被保留下來，無論有沒有人記得改名。
先打開變更日誌，才問改了甚麼
變更日誌列出圖表的每一次修改、是誰做的、改了哪個欄位，所以「星期二之後改了甚麼」只是捲一份清單，不是一場記憶考驗，也不用瞇着眼比對兩張匯出的圖片。
對兩個版本做差異比對，而不是肉眼比對兩份匯出檔
用比較版本選取任何兩個已儲存版本，逐個欄位看差異——方框、連線與標籤的改動會分別被標出新增、刪除或修改，而不是留給讀者在兩份攤平的 PDF 之間自己找出來。
還原，而不是憑記憶重建
如果一次修訂結果是錯的，還原較早的版本，而不是靠一份舊匯出檔手動重畫。這次還原本身會成為歷史裡的新一項紀錄，所以現行草稿的來龍去脈不會有任何遺失。
把圖表本身當成主版本，不是它的匯出檔
把你分發的 PDF 或 PNG 當成給讀者看的一張快照，絕不當成你會用來重建的紀錄——帶有版本歷史的那份可編輯圖表，才是唯一能回答「三月的時候是甚麼樣子」的那一份，匯出檔做不到。
應避免的錯誤
檔案名稱裡的「(2)」，就是破綻
一個已經有版本編號的檔案名稱後面，再多加一個括號裡的數字，代表兩個人同時編輯了同一份「最新」副本，卻沒有辦法合併。要修的不是一套更好的命名慣例，而是徹底不再需要命名慣例——一張圖表、一份歷史，沒有副本可以互相衝突。
匯出的 PDF，壽命比它來自的圖表更長
一份貼在牆上或附在舊電郵裡的 PDF，會在它匯出的那張圖表早已推進之後，繼續流傳很久，而 PDF 本身完全沒有任何跡象顯示這一點。把每一次匯出都當成一出生就過時，並且連結回那張即時圖表，而不是重新分享那個檔案。
把檔案版本控制，錯認成圖表版本控制
OneDrive、Google Drive 與 Dropbox 都能交回昨天的檔案，但它們都無法告訴你一個決策方框多了一條分支，或者一條連線的標籤改了——它們為容器做版本，不是為容器裡的內容做版本。那個差異，只存在於繪圖工具本身的歷史裡。
默默還原，而不是留下紀錄
把一份舊匯出檔的內容貼回現行檔案，會抹去曾經發生過還原這件事本身。一次會產生自己新的、有日期紀錄的還原——就像 QueryChart 那樣——令回滾的原因對下一位讀者保持可見，而不是看起來這張圖表一直都是這個樣子。
建立你自己的版本受控流程圖
把版本編號示例開成你自己的圖表，然後提交一次審閱，看着一個具名版本、變更日誌與比較版本自動為它出現。
相關指南
常見問題
流程圖版本控制跟文件版本控制有分別嗎？
原則上沒有——兩者都是保留某樣東西每一個過去的狀態，令你能看到改了甚麼、並退回那個狀態——但流程圖的「改了」是結構性的：哪個方框搬動了、哪條連線加上了、哪個標籤改了措辭。一套圍繞文字與頁碼建立的文件版本控制流程，不會為一條決策分支做差異比對。這個問題聚焦在整份流程文件而不是單一圖表的版本，見 /yue/guides/流程文件與流程圖的版本控制。
把流程圖匯出成 PDF，算是版本控制嗎？
不算——那是一張快照，不是歷史。一份 PDF 捕捉的是一個瞬間，無法自動跟另一份 PDF 比對來顯示改了甚麼，無法被編輯回去，也不帶有誰做了上一次改動、或者為甚麼改的紀錄。它適合用來跟讀者分享一份固定的副本；不能替代圖表本身的版本歷史。
QueryChart 裡的變更日誌跟比較版本有甚麼分別？
變更日誌是時間線——每一次修改、是誰做的、大約何時做的，由上至下讀。比較版本回答的是一個較窄的問題：選取任何兩個已儲存版本，逐個方框、逐條連線看它們之間欄位級的差異，而不用捲完整份日誌，自己重建出來。
還原一張流程圖的舊版本，會不會失去目前的工作？
不會——在 QueryChart 裡還原一個舊版本，會建立一個新版本，而不是刪除它之後的那些版本，所以其後所做的工作仍然留在歷史裡，即使它不再是使用中的狀態。還原這個動作本身，沒有任何一步是破壞性的。
