版本控制與文件管理
版本控制與文件管理，不是兩個要二選一的選項。版本控制是文件管理裡的其中一個機制，跟存取控制、元資料、保存與工作流程路由並存。
文件管理，是管治一份文件橫跨整個生命周期的較廣泛紀律；版本控制是它其中一個機制——追蹤那份文件連續版本的那一個——不是一套與它競爭的組織系統。
簡而言之
- 文件管理是那套紀律；版本控制是其中一個機制，不是一套用來取而代之的競爭系統。
- 版本控制回答的是「這是哪個修訂、改了甚麼」。文件管理還會回答誰可以看它、它住在哪裡，以及它何時到期檢討。
- 一套文件管理系統，通常會把存取控制、元資料與分類、保存時間表與工作流程路由，包裹在一份版本歷史周圍。
- QueryChart 免費的版本歷史——帶欄位級差異的變更日誌、比較版本、還原——是那個版本控制層；它本身不會設定存取權限或保存日期。
- 「版本控制對文件管理」，是一個問錯了的問題。真正的問題是，你的文件管理系統裡面，有沒有真正的版本控制。
一個是整份工作；另一個只是其中一部分
找十個人定義文件管理與版本控制，總有幾個會不自覺假設兩者是二選一的替代方案。它們不是替代方案。文件管理，是管治一份文件整個生命的紀律：誰可以看它、權威副本住在哪裡、它如何被分類與檢索、保留多久，以及一份草稿如何經審閱走到審批。版本控制是那套紀律裡的其中一塊——追蹤文件本身連續版本的那一塊，令你能看到改了甚麼、誰改的，以及在改錯了的時候回滾。這一塊本身的樸素定義，見 /yue/guides/文件sop與流程的版本控制是甚麼。
把兩者並排放在一起，關係的形狀就很明顯：每一套文件管理系統都需要版本控制，但幾乎沒有一套自稱版本控制的東西，能夠獨力做完文件管理其餘的工作。一份版本歷史——包括 QueryChart 免費的變更日誌與比較版本畫面，見 /features/version-control——回答的是「修訂 3 與修訂 4 之間改了甚麼、是誰改的」。它對誰獲准打開檔案、哪個資料夾是權威的，或者文件下一次何時到期檢討，沒有任何意見。這些是文件管理的問題，一套真正的文件管理流程，會把它們送經具名的步驟，而不是留給剛好記得的人。
下面的文件管制圖表，把這條界線變得具體。二十列把一份文件由變更申請，帶過起草、審閱、審批、簽發到退役，而其中確切只有一列——「訂定版本與生效日期」——是版本控制發生的地方。其餘十九列是存取控制、元資料、分發、培訓與一套保存時間表：單靠一個版本號做不到的文件管理功能。這些列所走的完整生命周期，完整覆蓋見 /yue/guides/如何建立文件管制流程；本頁只講其中哪些部分是版本控制、哪些不是。
一個流程，哪些列是版本控制
看着一份文件走過申請、起草、版本化與撤回，看清楚這條鏈裡有多少根本不是版本控制。
一項變更被申請——還未有任何版本存在
起點列是一個事件，「識別文件需求或變更」，直接流進「提出文件變更申請」。這是工作流程路由，捕捉為何需要一次變更這項文件管理功能，發生在任何東西擁有版本號之前。
只有一列鑄造版本；其餘是審批路由
「草擬或修訂內容」進入一個審閱循環——「進行技術審閱」、「有待處理的意見？」判斷、「按意見修改草稿」——然後是審批人的「批准簽發？」關卡。只有「訂定版本與生效日期」是版本控制；其餘都是工作流程路由。
登記冊、存取點與撤回，是文件管理，不是版本化
「更新文件總清單」是元資料與分類，寫成「檔案」形狀的列，令它顯示在圖上。「發佈到受控位置」是存取控制——一個權威位置，不是一份副本。「回收已作廢的副本」是分發控制，這三者沒有一個是儲存在版本號裡的。
保存與定期檢討，比任何單一版本活得更久
培訓或「閱讀並確認新版本」發生在「使用現行受控版本」之前，然後「觸發既定的定期檢討」按一個計時器重開紀錄。「文件是否仍然有效？」的出口是「記錄結論與下次檢討日期」、回到變更申請，或者「文件已回收並廢止」——一套保存時間表，單靠版本控制是運作不了的。
運作方式
指名你真正缺的是甚麼
如果沒有人答得出「上星期誰改了第 4 段、之前寫的是甚麼」，你缺的具體是版本控制。如果缺口反而是「誰獲准編輯這個」或者「大家應該信任的那一份副本在哪裡」，那是一個文件管理的缺口，單靠一份版本歷史補不上。
查核一份版本歷史實際上交出甚麼
一份真正的版本歷史，會顯示一份帶有逐個人、逐個欄位差異的變更日誌——不只是一個修改日期——加上一個能把任何兩個版本並排比較、並還原一個舊版本的方式。QueryChart 的變更日誌與比較版本畫面（/features/version-control），是在你接受一個工具聲稱的「版本歷史」之前，該期望看到甚麼的一個實際範例。
分開找出其餘四項功能
存取控制（誰可以查看或編輯）、元資料與分類（文件如何被找到）、保存排程（保留多久、何時檢討），以及工作流程路由（一份草稿如何變成一份已批准、已發放的文件）。沒有一項活在版本號裡面，所以要逐一審視，而不是假設一份版本歷史已經覆蓋了它們。
不要為了一個機制，去買整套紀律
當你需要以上四項功能一併被強制執行時，一套重型文件管理系統才有道理。如果實際缺乏的，只是看到改了甚麼並且能夠撤回的能力，那是一個小得多的問題，一個帶有真正變更日誌的圖表工具就能解決，不用連帶其餘那一整套推行。
把這個分別對應到你自己的流程
把你文件的生命周期畫成一列列，並標出哪一列單獨鑄造一個版本，就像下面圖表標出「訂定版本與生效日期」那樣。圖上其餘一切都是文件管理，這樣鋪陳出來，通常就足以確定一個團隊實際缺的是哪一項。
應避免的錯誤
明明想講「版本控制」，卻用了「變更控制」
一個變更諮詢委員會批准一張變更票，跟一個比較版本畫面為兩個文件修訂做差異比對，解決的是不同的問題，而兩者被混為一談的次數多到值得有它們自己的一頁——兩者在哪裡分歧，見 /yue/guides/版本控制與變更控制的分別。
把「最後修改日期」當成版本歷史
共用磁碟檔案上的單一個時間戳，只告訴你文件改動過，不告訴你改了甚麼、誰改的，或者如何取回之前的措辭。那不是版本控制，那只是一個關於有事情發生過的傳聞。
假設買了文件管理系統，就自動包含真正的版本化
不少文件管理系統，儲存檔案時附有豐富的元資料與存取規則，卻只有一份淺薄的修訂清單，沒有欄位級差異、也沒有一鍵還原。要具體確認版本歷史，而不是從平台其餘部分去推斷它存在。
實際看看版本歷史的運作
把文件管制示例開成你自己的圖表，然後查看它的變更日誌，看清楚同一個分別——一個版本被蓋上戳記、一個欄位被做了差異比對、一個舊修訂可以被還原。
相關指南
常見問題
版本控制是文件管理的一部分，還是跟它分開的？
是一部分。文件管理是那套管治紀律——存取、分類、保存、工作流程與版本化合在一起——版本控制則是其中追蹤文件連續修訂的機制。把兩者當成要二選一的選項，正是本頁存在的目的所要糾正的誤解：一套沒有版本控制的文件管理系統，缺了一項核心功能；而一份周圍沒有存取控制或保存政策的版本歷史，還不算是文件管理。
只是為了得到版本控制，就需要一整套文件管理系統嗎？
不需要。版本控制是較窄的能力——一份帶欄位級、逐個人差異的變更日誌、一個比較兩個修訂的方式，以及一條還原路徑——一個圖表工具就可以獨力提供，免費並且常駐運作，就像 QueryChart 的版本歷史那樣；見 /features/version-control。當你還需要強制執行的存取權限、正式分類，以及橫跨多份文件運作的保存時間表時，一套完整的文件管理系統才是正確的採購，而不是在真正缺乏的只是看到改了甚麼的時候。
版本控制跟變更控制有甚麼分別？
版本控制追蹤一份文件連續的狀態——修訂 3 與修訂 4 之間改了甚麼。變更控制管治的是應否做出一次變更這個決定本身，通常透過一個諮詢委員會、一次風險評估與一個回滾方案，多數用於 IT 系統或營運流程，而不是單一個檔案。一個文件管制流程兩者都用：發放一次修訂之前，有變更控制式的審批關卡，並用版本控制記錄修訂本身。完整分別見 /yue/guides/版本控制與變更控制的分別。
版本控制在一個文件管制流程裡，坐落在哪裡？
在單一個點：修訂獲批之後，訂定版本號與生效日期的那一步。它之前的一切——變更申請、起草、審閱——與它之後的一切——發佈到受控位置、回收已作廢的副本、培訓、定期檢討——都是文件管理在做單靠一個版本號做不到的工作。這些階段所取材的完整二十列流程，見 /yue/guides/如何建立文件管制流程。