文件版本控制最佳做法
給已經有編號方案的團隊：文件版本控制最佳做法——保持方案穩定、固定版本／日期／審批人出現的位置、杜絕並行編輯現行副本，並記錄每一次沒有變更的檢討。
文件版本控制最佳做法，是令一套既有編號方案，在多年的人員流動與文件量之下仍然值得信賴的習慣，而不是最初選定那套方案的規則。
簡而言之
- 方案一旦選定就保持穩定——重新編號會弄斷每一份引用過舊編號的交叉引用。
- 把版本、日期與審批人印在每一頁同一個固定位置，不要只放在檔案名稱或屬性裡。
- 絕不讓兩個人在沒有鎖定或簽出慣例的情況下，並行編輯「現行」版本。
- 預先以書面訂明，甚麼算大改、甚麼算小改。
- 把「不需要變更」當成一個有紀錄的檢討結果，而不是沉默。
- QueryChart 用一張正式的即時圖表，取代了簽出慣例——見 /features/version-control。
一套方案，好不好要看它的第二年
一套編號方案，很少在第一個月就失效。它失效在第二年——當初訂下「已發放副本用整數」那個人已經離職，新上任的文件管理員為了應付一宗緊急個案，發明了一條稍有不同的規則，於是兩套慣例開始同時在同一本登記冊裡運作。本頁假設基本決定已經做好——最初選定一套方案，見 /yue/guides/如何為文件做版本控制——講的是那一小撮習慣，令選定的方案在真實的文件量、人員流動與緊急情況衝擊之下，仍然行得通。
方案選定之後，通常有四件事會出錯，而沒有一件跟方案本身有關。為修正一個看似存在的缺陷，去重新編號一個既有的檔案庫，會弄斷每一份引用過舊編號的交叉引用、培訓紀錄與過往審計引用，所以代價通常高過忍受那個缺陷。一個只活在檔案名稱或屬性面板裡的版本號，一旦有人列印一頁或轉發截圖就會消失，所以需要一個固定、印出來的位置。兩位作者在同一個下午編輯同一份「現行」檔案，根本不是編號問題——是缺少一套鎖定或簽出慣例，沒有它，任何方案都撐不住。而一次甚麼問題都沒找到的定期檢討，仍然要留下一個記號，否則一年之後，它跟一次從未發生過的檢討沒有分別。這些都不是文件的整個生命周期——由申請到退役完整走一遍見 /yue/templates/文件管制流程——這些是那個生命周期裡的編號一層，做得好，而不只是做了。
QueryChart 從結構上而不是靠政策，移除了其中一種失效模式。每一份文件只有一張正式的即時圖表，而不是一組要靠人記得鎖定的檔案；每一次儲存都會自動被捕捉為變更日誌裡的一條新項目，附上是誰做的與確切改了哪個欄位；比較版本把任何兩個版本並排顯示。兩個人不可能悄悄各自分岔出一份「現行」副本，因為根本只有一份，它整段歷史是一次查詢，不是一場記憶測驗。見 /features/version-control。
這些做法，在一份文件的一生裡出現在哪裡
同一張 18 列的文件版本控制圖表，這次讀的不是編號步驟本身，而是甚麼令它的編號方案撐得住。
方案在任何人審閱任何東西之前就已經開始
「訂定初始草稿版本 0.1」緊接在「新文件已開始草擬」之後就發生，早於「把草稿分發作內部審閱」或「審閱人評估草稿」——小數方案在第二列就已經定下來，不是在第一次「是否需要修改？」判斷走到一半才發明出來的。
返工只會遞增，絕不重新編號
「遞增小數版本」與「按意見修改草稿」，經一條標籤為「重新審閱」的分支循環返回審閱，早於「提交定稿作審批」與「審批人審閱定稿」——同一條小數規則貫穿每一次循環，所以談及草稿 0.3，指的仍然是一份確切的副本。
一個判斷，劃出大改與小改的界線
「是否批准發放？」是唯一一列通往整數的路：「批准」分支到達「訂定整數版本 1.0」，「駁回」則循環返回「遞增小數版本」——然後「更新版本歷史登記冊」、「發布已批准的版本」與「把上一版本標示為作廢」，在任何人讀到新副本之前，把這個決定固定在一列「檔案」形狀的列裡。
不需要變更的文件，仍然留下一個記號
即使答案是「否」，「發布後是否有變更要求？」依然會被回答——那條分支結束於「現行版本維持生效」，一個具名的結果，而不是活動的缺席；答「是」則在「以下一個版本重新開啟文件」重開文件，而不是在旁邊另開一份副本。
運作方式
一旦真實文件依賴於它，就凍結編號方案
把方案本身的改動——由整數改成語意化版本編號、或者重新定義小數的意思——當成一個項目，不是一次微調：它會令每一份既有的交叉引用、培訓紀錄與過往審計引用全部失效。如果發現一個缺陷，就把例外向前記錄下來，而不是為整個檔案庫重新編號。
把版本、日期與審批人放在每個範本的同一個固定位置
選定一個位置——頁首或頁尾——並把它烙進文件範本，令每一位作者都不用另外決定就照用。一個只活在檔案名稱或文件屬性裡的版本號，撐不過列印、截圖或電郵轉發；印在頁面上的可以。
給「現行」版本一套鎖定或簽出慣例
決定同一時間可以有誰把現行版本打開來編輯，以及第二位作者如何得知已經有人在編輯——登記冊裡的一個簽出標記、一個鎖定的檔案，或者一份單一、正式的即時副本，一次只有一個儲存能夠生效。沒有這個，兩次已批准的編輯同時落在同一個版本上，不是一個假設情況。
在第一份文件用得着之前，先寫下大改對小改的規則
在定義編號方案的同一份文件裡，準確訂明甚麼觸發整數躍升——單是正式審批，還是審批加上大幅改寫。一個逐一個案決定這件事的團隊，最終會有兩份不同文件都叫做版本 2.0。
記錄每一次定期檢討，包括甚麼都沒改的那些
給檢討這一步一個「決策」形狀，並附一個標籤為「無變更」的出口，寫入登記冊一條有日期的項目，就像「發布後是否有變更要求？」到達「現行版本維持生效」，而不是甚麼都不做。一條缺失的項目，應該代表檢討沒有發生，而不是代表檢討期間甚麼都沒發生。
讓單一份正式的即時副本，徹底移除鎖定問題
把文件開成一張 QueryChart 圖表，而不是一組靠電郵傳來傳去的檔案，就只有一個現行版本可以編輯——每一次儲存都會自動被捕捉為變更日誌裡的一條新項目，所以簽出慣例已經沒有甚麼需要執行。見 /features/version-control。
應避免的錯誤
為修正一個錯誤而重新編號
兩年後才發現方案有一個缺陷，然後為修正它重新編號整本登記冊，會弄斷每一份引用過舊編號的引用——審計、培訓紀錄、其他文件裡的交叉引用。改為把例外向前記錄下來；已發放的文件，就忍受那個缺陷。
只活在檔案名稱裡的版本號
「Policy_v3_FINAL.docx」一旦被列印、轉發，或者在沒有帶着名稱的情況下被複製，就對任何人都毫無意義。把版本、日期與審批人放進文件本身，每一次都是同一個固定位置。
同一個下午，兩份「現行」副本都被編輯
共用磁碟上的一份副本，跟電郵寄出的一份副本，都被當成主版本來編輯，於是兩組改動悄悄互相覆蓋，或者分岔開來。用一套簽出慣例修正這個問題，更好的做法是採用單一份正式的即時副本——見 /features/version-control。
沒有改動時，檢討沒有留下痕跡
一份文件被檢討過，發現仍然準確，卻沒有在任何地方留下項目，一年之後就跟一份從未被檢討過的文件沒有分別。給「不需要變更」在登記冊裡它自己一行有日期的紀錄，就像一列決策的「否」分支仍然到達一個具名的結果。
把這些做法套用到你自己的文件
把文件版本控制示例開成你自己的圖表，讓一份正式的即時副本加上自動的變更日誌，替你執行本頁上的規則。
相關指南
常見問題
文件版本控制最應該避免的單一最大錯誤是甚麼？
把方案當成只到有人找到理由改動它為止的暫定安排。重新編號一個既有的檔案庫——即使是為了修正一個真實的缺陷——會弄斷每一份引用過舊編號的交叉引用、培訓紀錄與審計引用，而這個代價幾乎總是高過忍受一套不完美方案的代價。以一項有記錄的例外，向前解決問題，而不是去改動已經發放的東西。
如何阻止兩個人同時編輯同一份「現行」版本？
要麼加一套明確的簽出慣例——登記冊裡的一個標記，顯示誰正在打開這份文件，讓第二位作者知道要等——要麼從結構上移除這個可能性，只保留單一份正式的即時副本，而不是靠電郵或共用磁碟傳遞的檔案。QueryChart 做的是後者：每一份文件都是一張即時圖表，每一次儲存都自動變成一個版本，沒有第二份副本可以分岔。見 /features/version-control。
甚麼應該算大改，甚麼算小改？
沒有一條放諸四海皆準的規則，這正是為甚麼它必須在第一份文件用得着之前寫下來，而不是逐一個案判斷。一個常見的慣例，是把整數的大改躍升，單純繫於正式審批——期間任何一次草稿修訂，無論多實質，都維持小數——這樣「這次改動有多大」，就永遠不用在配給版本號那一刻才拿出來爭論。
一次沒有發現需要變更的定期檢討，需要記錄嗎？
需要——一次沒有記錄的檢討，跟一次從未發生過的檢討沒有分別。給你流程裡的檢討步驟一個「決策」形狀，並附一個標籤為「不需要變更」的出口，仍然向登記冊寫入一條有日期的項目，就像一列決策記錄它所走的每一條分支，不只是那些通向新地方的分支。
