版本控制與變更控制的分別
版本控制追蹤哪個修訂現行、改了甚麼；變更控制則決定一項擬議變更應否獲准發生，以及誰要先批准它。
版本控制是識別並記住文件連續狀態的機制；變更控制則是決定一次變更是否獲准，才有新版本誕生的管治流程。
簡而言之
- 版本控制追蹤身份與歷史：這是哪個版本，以及之前是甚麼。
- 變更控制是管治：一項擬議變更是否獲准，以及誰要批准它。
- 變更控制先運作——分類與審批把守着進入一個新版本的入口，不是反過來。
- 一次小改與一次大改，可以承受不同程度的變更控制，卻不會改變版本控制的運作方式。
- 大部分真實流程兩者都需要，一層疊一層：變更控制負責決定，版本控制負責記住。
兩個不同的問題，同一個對象
「這是哪個版本？」與「這項變更應否發生？」是兩個不同的問題，而大部分流程文件只回答第一個。版本控制是一套標籤與歷史機制：它為文件的每一個連續狀態配一個識別碼、保留它之前狀態的紀錄，並讓你看到誰改了甚麼、何時改的。它回答的是事後的保管問題。變更控制則坐落在它上游：是決定一項擬議變更是否獲准、誰必須審閱它，以及在一個新版本獲准存在之前，甚麼條件必須成立的管治流程。
下面的文件變更控制工作流程，把這條界線變成一張圖表，而不只是一句話。第 1 到 8 列，完全是變更控制：記錄申請、把它分類為小改或大改、把大改送去給一位評估完整影響的審閱人，並把一切卡在一個「是否批准？」判斷之下。這些完全沒有觸及文件的版本。只有通過審批關卡之後，「更新版本號與分發清單」才在第 9 列執行——正是版本控制開始的那一點。
QueryChart 以同樣的方式，把兩者分開。圖表的每一次修改，都會自動被捕捉進一份帶欄位級差異的變更日誌，附有比較版本畫面與一鍵還原——那是版本控制，無論有沒有人要求，它都在運作，見 /features/version-control。某一次具體修改一開始是否獲准發生，以及是誰簽署核准的，則是下面這種圖表所回答的管治問題。那套管治流程較完整、更偏向 IT／營運的版本，而不是這個文件專屬的版本，見 /yue/guides/如何建立變更控制流程。
變更控制在哪裡結束，版本控制在哪裡開始
一份文件的分類、審閱與審批——然後是它的版本號實際改變的那一列。
一項申請，還未是一次版本變更
「已識別受控文件需要變更」開始這張圖表，然後是「提交文件變更申請」與「把申請記錄在文件檔案上」——三列變更控制，文件的版本仍然沒有被碰過。
分類與審批把守一切
「變更分類為小改還是大改？」分岔成一次快速通道編輯，或者一次完整審閱，由變更審閱人「評估完整影響」，並記錄它對相關文件及表格的影響，才到「是否批准？」判斷——到這裡，版本號都還沒有被碰過。
第 9 列，是版本控制開始的地方
只有變更獲批之後，「更新版本號與分發清單」才會執行，接着是發布到受控位置、通知分發清單持有人，以及回收已作廢的副本——這正是整個流程裡版本控制的那一半。
被駁回會循環返回變更控制
答「駁回」會把申請送去「修訂草稿並重新提交審閱」，返回變更審閱人的影響評估——返工完全留在變更控制之內，直到「文件已在正式變更控制下重新發放」以一個新版本結束這張圖表。
運作方式
在你自己的流程裡，把兩個問題分開
在畫任何東西之前，先決定甚麼屬於變更控制（申請、分類、審閱、審批），甚麼屬於版本控制（識別碼、修訂編號、歷史、還原）。點名這條界線，是大部分流程圖都略過的設計步驟。
先分類，才評估
在評估開始之前，把每一項申請都送經一個小改／大改判斷，就像第 4 列那樣。一次措辭上的小修正，跟一次要求上的大改動，不應該走同一條審閱路徑，預先決定哪個是哪個，能阻止每一項變更都被套上最重的審視。
把版本控制步驟，放在審批真正結束的地方
只在通過審批關卡之後，才遞增版本號、設定生效日期並更新分發清單，絕不能更早。如果你的圖表在那個決定之前就更新版本，就等於描述了一個連被駁回的草稿都會版本化的流程。
給變更控制它自己的審閱人，而不是文件負責人
一位變更審閱人，評估完整影響並記錄它對相關文件及表格的影響，跟申請變更的人分開，這正是「已批准」這個字有意義的原因。在示例裡，這一步坐落在分類與審批決定之間，不是併進其中任何一個。
變更控制決定之後，讓版本控制自行運作
一項變更獲批之後，發布、通知分發清單持有人與回收已作廢的副本，都是機械性的——這是圖表裡版本控制的那條尾巴，也正是 QueryChart 的變更日誌與比較版本畫面，已經替你處理好的那一半，見 /features/version-control。
應避免的錯誤
把「我們有版本歷史」，當成變更控制
一個為每一次修改蓋上時間戳的工具，不是一套管治流程——它沒有分類、沒有審閱人、也沒有審批關卡。版本歷史回答的是改了甚麼；它對這次變更應否發生，沒有任何說法。
在一項變更獲批之前就將它版本化
如果版本號在「是否批准？」判斷之前就已經移動，一份被駁回的草稿，仍然會顯示為一個新修訂。把遞增保持在第 9 列，審批之後，就像示例那樣。
所有變更都用同一個類別
把一次錯別字修正，跟一次要求上的改動送經同一套審閱，要麼拖慢瑣碎的修改，要麼讓實質性的變更走快速通道溜過去。第 4 列的小改／大改分岔存在，正是為了讓兩者都獲得適當程度的審視；如何設計類別本身，見 /yue/guides/如何建立變更控制流程。
在你自己的圖表裡比較版本
這個示例的每一次修改，已經自動被追蹤——打開它，親自查看變更日誌與比較版本畫面。
相關指南
常見問題
版本控制跟變更控制是同一回事嗎？
不是。版本控制是識別並記住文件連續狀態的機制——一個修訂編號、一份誰改了甚麼的歷史，以及比較或還原較早版本的能力。變更控制則是決定一項擬議變更是否獲准發生、由誰審閱、獲批之前甚麼條件必須成立的管治流程。一份文件可以有嚴謹的版本控制，卻完全沒有變更控制：每一次修改都被儲存，卻沒有人決定它應不應該被做出來。
應該先建立哪一個？
版本控制，因為它通常已經在你底下運作：QueryChart 為每一張圖表自動保留一份帶欄位級差異的變更日誌，附有比較版本畫面，見 /features/version-control。變更控制則是你必須刻意設計的部分——類別、一位審閱人、一個審批關卡——這正是為甚麼它是一個值得畫成流程圖的流程，就像本頁這一張。
這跟修訂控制有甚麼分別？
實際上，「修訂控制」與「版本控制」是同一套機制的不同名稱，兩者關心的都是識別並追蹤文件連續的狀態。變更控制才是不同的那一個：它管治的是一項變更一開始是否獲准，通常在獲批之後以一個新版本結束。如果你要解決的具體是修訂控制／版本控制這個命名問題，見 /yue/guides/修訂控制與版本控制的真正分別。
文件管制在這兩者之間，坐落在哪裡？
文件管制是三者之中最廣的一個：一份受控文件的完整生命周期，由申請經起草、審閱、審批、發布，到最終撤回或退役。變更控制與版本控制都是它的其中一塊——變更控制管治單一項擬議修改，版本控制追蹤那次修改所產生的識別碼與歷史。要看整個生命周期，而不只是變更／版本這條界線，見 /yue/templates/文件變更控制流程，或者較廣的 /yue/guides/如何建立文件管制流程。