文件、SOP與流程的版本控制是甚麼
大多數「版本控制是甚麼」的搜尋結果，假設你在管理的是 Git 與程式碼。本頁改為文件、SOP 與流程定義它，並把它與修訂控制、變更控制、文件管制分開。
版本控制是一種做法：為一份文件、SOP 或流程保持一個現行、具權威性的版本，同時保留它之前每一個版本的完整歷史，以及誰改了甚麼的紀錄。
簡而言之
- 版本控制，是一個現行版本，加上每一個舊版本的完整歷史，加上誰改了甚麼的紀錄——文件和程式碼背後是同一個概念。
- 修訂控制是同一種做法的另一個名稱；變更控制與文件管制則是更廣泛的流程，只把它當成其中一部分來用。
- QueryChart 已經為每一張圖表保留這份歷史：變更日誌、比較版本畫面，加上一鍵還原——見 /features/version-control。
- 草稿的小數版本（0.1、0.2……）每一個審閱循環就會移動；整數版本只在正式審批那一刻才會訂定一次。
- 要為某一種特定對象做版本控制？見 /yue/guides/如何為sop做版本控制、/yue/guides/如何為文件做版本控制 或 /yue/guides/流程圖版本控制實際運作方式。
一個現行版本，其餘全部是歷史
搜尋「甚麼是版本控制」，幾乎每一個結果都假設你在管理程式碼——提交、分支、Git。本頁講的是這個詞較舊、較樸實的用法：控制的是文件、標準作業程序與業務流程的版本，而不是程式碼。兩者背後的概念其實一樣：一個現行、具權威性的版本；它之前每一個版本的完整歷史；以及誰改了甚麼、何時改的確切紀錄。分別只在於被版本化的對象——是文書工作，不是程式碼庫。
具體來說，這代表每一次修改文件都會產生一個新的、有編號的版本，而不是覆蓋上一個版本，令舊版本仍然可以取回，而不是就此消失。在 QueryChart 裡，你建立的每一張圖表已經具備這一點：變更日誌會記下誰改了哪一個欄位、由甚麼改成甚麼；比較版本畫面可以把任何兩個版本並排顯示；還原一個舊版本只是一個動作，不用重新輸入——完整說明見 /features/version-control。以上一切都不需要另外開啟，圖表由建立的一刻起就已經在運作。
修訂控制與版本控制是同一個概念的兩個名稱——這個領域裡大部分時候，兩個詞可以互換使用，機構偏好用哪一個並不影響實質。變更控制與文件管制是另一回事：它們是更廣泛的管治流程，只是把版本編號當成其中一種機制，而不是版本控制的同義詞。變更控制流程（機制見 /yue/guides/如何建立變更控制流程）決定一項變更應否發生——影響、審批、回滾；版本控制只是核准之後，把結果編號並記錄下來的方式。文件管制流程（範本見 /yue/templates/文件管制流程，操作方法見 /yue/guides/如何建立文件管制流程）管治一份文件的整個生命周期——起草、審閱、審批、發布，並把被取代的副本從它出現過的每一個地方撤回——版本控制只是其中一項條款，不是它的全部。這三組配對各自有完整比較，分別在 /yue/guides/版本控制與變更控制的分別、/yue/guides/版本控制與文件管理 與 /yue/guides/修訂控制與版本控制的真正分別；本頁只需要你明白，它們不是同一件事的四種講法。
如果你已經知道自己要為哪一種對象做版本控制，上面的一般答案就不及針對性的答案有用：標準作業程序見 /yue/guides/如何為sop做版本控制，一般受控文件見 /yue/guides/如何為文件做版本控制，如果你要版本控制的正是流程地圖本身，見 /yue/guides/流程圖版本控制實際運作方式。下面的一切——精簡定義、示例走一遍、操作步驟——都是這三頁在其上建立的一般情況。
逐階段看着一個版本號被訂定
一份文件由小數草稿，經審閱、審批走到發布——看清楚它的版本號在哪裡改變，在哪裡不變。
草稿由 0.1 開始，不是 1.0
圖表由「新文件已開始草擬」開始，隨即進入「訂定初始草稿版本 0.1」——一個小數，因為在這套編號方案裡，正式審批之前的任何東西都不會獲派整數。
審閱循環會推進小數版本
「把草稿分發作內部審閱」與「審閱人評估草稿」引向「是否需要修改？」。答「是」就經「遞增小數版本」——0.1 變成 0.2——進入「按意見修改草稿」，再經一條標籤為「重新審閱」的分支循環，草稿需要多少個循環就走多少次。
整數是掙回來的，不是預設的
「提交定稿作審批」與「審批人審閱定稿」帶到「是否批准發放？」。駁回會循環返回「遞增小數版本」；批准則到達「訂定整數版本 1.0」，以及把它記下來的「檔案」形狀列——「更新版本歷史登記冊」。
發布同一列就把舊版本退役
「發布已批准的版本」緊接就是「把上一版本標示為作廢」，令舊修訂在新版本上線的一刻就被退役。讀者要求變更會重新進入「以下一個版本重新開啟文件」；其餘所有人到達「現行版本維持生效」。
運作方式
選定一個位置作為權威版本
其餘每一份副本——電郵發出的 PDF、列印本、儲存到共用磁碟的頁面——都是那一個位置的副本，而不是第二份正本。如果有兩個地方都可以聲稱自己是現行版本，無論你的編號看起來多整齊，都還未算有版本控制。
把草稿編號與已發放編號分開
仍在審閱中的一律用小數，整數則只留給真正已獲批准的版本，就像上面示例圖表裡 0.1 到 0.3 走到 1.0 那樣。這樣審閱人談及「0.3 版的意見」時，指的是哪一份草稿就再無含糊。
記錄誰改了甚麼，而不只是有東西改了
單獨一個日期戳，不會告訴讀者實際改動了甚麼。每一次修改都要記下是誰做的、改了哪個欄位，以及改動前後的值——這正是 QueryChart 的變更日誌為每一張圖表自動做的事，無須任何設定。
令兩個版本可以比較，而不只是可以打開
可以打開版本 3，也可以打開版本 5，跟能夠看到兩者之間改了甚麼，並不是同一回事。QueryChart 的比較版本畫面把任何兩個版本並排顯示，令差異本身變成你看到的東西，而不是靠猜。
把還原舊版本當成例行工作，而不是緊急事故
如果要撤回一次錯誤修改，代表要找有資料庫存取權的人出手，你的版本控制就只是寫在紙上。還原一個舊版本，應該是任何獲授權的編輯者一發現問題就可以自行採取的動作。
應避免的錯誤
用檔案名稱充當版本號
「SOP_v2_FINAL_reviewed(1).docx」不是一套版本方案，只是一個剛好含有數字的檔案名稱——沒有任何機制強制編號一定上升，也沒有甚麼阻止兩個人同時各自弄出一個「FINAL」。版本需要活在一個負責派發編號的系統裡，而不是活在某人儲存前隨手打的字裡。
只記錄現狀的歷史
原地覆蓋一份文件，然後把舊副本說成「備份在某處」，那不是版本歷史，只是一個願望。一份真正的歷史，會令每一個舊版本都可以取回、可以比較，而不是只有記得放在哪裡的人才找得回來。
把「有版本號」當成「已受管制」
文件上有一個編號，只代表它曾經被版本化一次；並不代表舊副本已被撤回、有人批准過這次變更，甚至不代表這個編號真的是你以為的那個意思。版本控制是編號與紀錄——文件管制與變更控制，才是管治這個過程本身的東西。
改的是詞彙，不是做法
把機構統一用「修訂控制」而不是「版本控制」，或者反過來，並不會改變變更是否真的被追蹤這件事。它們是同一種做法的兩個名稱；真正要修的是那份紀錄，不是那個標籤。
在 QueryChart 查看你圖表的變更日誌
QueryChart 裡每一張圖表都已經保留這份歷史——建立一張，打開它的變更日誌親自看看。
相關指南
常見問題
版本控制與修訂控制是同一回事嗎？
實際上是。兩個詞描述的是同一個底層概念——一個現行版本，加上每一個舊版本都可以取回的歷史——不同機構、工具與標準只是各自偏好其中一個字眼。無論用哪一個詞，運作機制都不會因此改變；完整比較見 /yue/guides/修訂控制與版本控制的真正分別。
版本控制與變更控制有甚麼分別？
變更控制決定一項變更應否發生——它的影響、由誰批准、出錯時如何回滾。版本控制則是那個決定作出之後，用來記錄結果的東西：新的編號、時間戳、是誰做的。一個變更控制流程可以在沒有版本控制的情況下存在，只是做得很差；而版本控制沒有變更控制，就代表在編號之前，沒有人決定過這項變更是否值得做。CAB 與回滾的機制見 /yue/guides/版本控制與變更控制的分別 與 /yue/guides/如何建立變更控制流程。
文件的版本控制運作方式，跟程式碼一樣嗎？
核心概念完全一樣——一個具權威性的現行版本、之前一切的完整歷史、誰改了甚麼的紀錄——但機制不同。像 Git 這樣的程式碼版本控制，建立在分支與合併並行工作線之上；文件與流程的版本控制通常是線性的，一份草稿經審閱走到單一個已批准的版本，這更接近本頁與示例圖表所描述的樣子。
QueryChart 的審計軌跡是預設開啟的嗎？
本頁描述的版本歷史——變更日誌、比較版本、還原——是免費的，並在每一張圖表上自動運作，無須任何設定。QueryChart 的合規審計軌跡，是一份對應 ISO 27001、SOC 2 與 HIPAA 控制項的雜湊鏈紀錄，是一項獨立的付費功能，需要機構主動開啟。它不是預設開啟的，也不是每一個帳戶本來就已經在運作的東西。
