如何為文件做版本控制

簡而言之

• 草稿版本用小數（0.1、0.2……）；已發放版本用整數——絕不倒過來。
• 把版本、日期與審批人印在每一頁的頁首，不要只放在檔案名稱或檔案屬性裡。
• 只保留一個權威的現行位置；其餘所有引用都連結過去，而不是各自持有一份副本。
• 在第一份文件用得着這條規則之前，先以書面訂明甚麼算整數版本躍升、甚麼算小數版本。
• QueryChart 的變更日誌與比較版本畫面，準確顯示兩個版本之間改了甚麼，無須人手記錄——見 /features/version-control。

版本號，是一項關於信任的聲明

兩個人編輯同一份文件，卻沒有編號規則，結果總是一樣：一個叫做 Policy_v2_FINAL_reviewed_USE-THIS-ONE.docx 的檔案，加上沒有人確定三份開着的副本裡哪一份才是真正現行的。文件的版本控制，靠三項具體決定解決這個問題，而不是一個塞滿日期檔名的資料夾：一套編號方案、每一頁都聲明自己版本的位置，以及一個所有人都當成權威的單一存放地點。

版本控制不等於變更控制，也比文件管制範圍窄。變更控制是決定一項擬議變更應否獲批的機制——影響評估、變更委員會、回滾方案——這條流程本身走一遍見 /yue/guides/如何建立變更控制流程。文件管制則是一份文件由頭到尾活在其中的完整生命周期，由啟動它的申請，到令它保持現行的定期檢討，完整覆蓋見 /yue/guides/如何建立文件管制流程 與 /yue/templates/文件管制流程。本頁比兩者都窄：它是在文件管制流程底下運作的編號與可追溯性一層，並不是要取代它。

QueryChart 不需要另外手動維護一本登記冊，就能令這一層編號保持誠實。圖表的每一次修改都會被變更日誌記下，寫明是誰改的、改了哪個欄位；比較版本畫面把任何兩個版本並排顯示，標明確切改了甚麼；還原一個舊版本只是一個動作——這是免費、常駐運作的版本歷史，完整說明見 /features/version-control。

看着一個版本號走過五條泳道

一份新文件經草擬、兩次修改、審批、發布到被取代——版本號在每一步都在改變。

1. 草稿誕生於 0.1

   圖表由「新文件已開始草擬」開始，在檔案還未被分發之前，「訂定初始草稿版本 0.1」已經給它一個小數編號——標誌着這是一份仍在內部審閱、尚未獲批准使用的草稿。

2. 每一個返工循環都掙得一個新小數

   「是否需要修改？」把需要返工的草稿經「遞增小數版本」送到「按意見修改草稿」，然後審閱人才再次看到它——0.1 變成 0.2，於是談及「0.3 版的意見」，指的就是一份確切的草稿。

3. 審批是通往整數的唯一大門

   「提交定稿作審批」與「審批人審閱定稿」帶到「是否批准發放？」——只有「批准」分支到達「訂定整數版本 1.0」；「駁回」則循環返回小數版本的循環。

4. 發布是取代，不是刪除

   「更新版本歷史登記冊」是「檔案」形狀的列而不是「流程」形狀，然後「發布已批准的版本」與「把上一版本標示為作廢」都在任何讀者打開新副本之前完成——舊編號仍然留在登記冊裡。

5. 已發布的文件仍然可以重開

   「讀者存取現行版本」與「發布後是否有變更要求？」顯示發布不是終點：答「是」會把文件經「以下一個版本重新開啟文件」送回審閱；答「否」則到達「現行版本維持生效」。

運作方式

1. 訂定你的小數對整數規則

   以書面訂明：仍在審閱中的草稿用小數——0.1、0.2、0.3；已發放的副本用整數——1.0、2.0。方案的具體細節不是重點，重點是每一份文件都用同一套，包括登記冊與每一頁的頁首。

2. 把版本、日期與審批人放在每一頁上

   一個只活在檔案名稱或文件屬性裡的版本號，一旦有人列印那一頁或轉發截圖，就會即時消失。把版本、生效日期與審批人姓名放在文件本身的頁首或頁尾。

3. 在需要之前，先定義甚麼掙得一個整數版本

   在第一份文件走到那一步之前，寫下觸發整數躍升的條件——單是正式審批，還是審批加上內容大幅改寫。一個從未就此達成共識的團隊，最終會有兩份不同文件都叫做版本 2。

4. 按次序把編號步驟輸入圖表

   開一張圖表，把每個階段——草擬、審閱、修改、審批、發布、取代——填進「方框文字」欄，用「連線至」欄把它們連起來。版面是自動生成的，所以唯一真正要決定的，是版本號走過的次序。

5. 指名唯一的權威位置

   選定現行版本存放的那一個地方——一個受控資料夾、一套文件管理系統，或一個即時的 QueryChart 連結——並令其餘所有引用都指向它，而不是各自持有一份副本。如果兩份「現行」副本可以互相矛盾，版本號就毫無意義。

6. 查看變更日誌，而不是四處問誰有最新副本

   打開圖表的版本歷史，用比較版本準確看到兩個版本之間哪一個欄位改了、誰改的、何時改的，而不是另外手動維護一份 changelog。變更日誌與還原如何運作，見 /features/version-control。

應避免的錯誤

• 永遠定不下來的小數

  一份草稿卡在 0.7，沒有人願意稱它為定案，這是審批觸發條件沒有訂明的徵狀，不是編號問題。要修的是甚麼掙得整數的規則，不是小數的數量。

• 一個沒有人看得見的版本號

  一個只記在試算表登記冊裡、文件本身卻沒有的版本，逼讀者只能相信自己手上那份跟登記冊相符。改為把它印在頁面上。

• 兩個地方都自稱現行

  共用磁碟上的一份副本，跟文件管理系統裡的一份副本，只要其中一份被改而另一份沒有，就會開始走樣。選定單一權威位置，並鎖定或淘汰其餘的。

• 放在文件旁邊、手動維護的變更清單

  一份手動維護、記錄「v3 改了甚麼」的清單，只要有人漏記一項，就會跟文件本身脫節。QueryChart 的變更日誌會自動記錄每一次欄位變更，所以應該比較兩個版本，而不是相信一則筆記。

建立你自己的版本受控文件

把文件版本控制示例開成你自己的圖表，訂下你的編號方案，此後每一次變更都交由變更日誌記錄。

建立你自己的版本受控文件

相關指南

• 如何為SOP做版本控制
• 文件版本控制最佳做法
• 版本控制與變更控制的分別

常見問題

文件版本控制是甚麼？

文件版本控制，是為文件的每一份草稿與已發放副本，各派一個獨立編號的做法，令任何持有一份副本的人，都能判斷它有多現行，以及它跟曾經存在過的其他副本是甚麼關係。它通常把小數方案配給仍在審閱中的草稿，整數則留給已正式獲批的版本，並且依賴每一頁都帶着那個編號，而不是把它留在檔案名稱或另一本登記冊裡。

文件版本控制的步驟，具體要怎樣做？

在起草任何內容之前，先訂定編號方案——草稿用小數、已發放副本用整數，是常見慣例。把版本、日期與審批人放在每一頁的頁首。令每一份草稿都走同一個審閱審批循環，每次返工遞增小數版本，只在正式簽署時才遞增整數版本。只保留一個權威的現行位置，並且把新版本取代的那一個標示——絕不刪除。

文件的「版本控制」與「修訂控制」有甚麼分別？

實際應用在文件上，兩個詞描述的是同一件事——一套為連續副本編號的方案——大多數品質系統把兩者互換使用。真正出現分別的場合，在於軟件與工程語境：「修訂控制」有時暗示一整套變更集的歷史，而「版本控制」則較鬆散地只指編號標籤本身。選定一個詞並保持一致使用，不要把一個實際上不存在的分別當成有意義；完整比較見 /yue/guides/修訂控制與版本控制的真正分別。

已經有版本號，還需要另外一份變更日誌嗎？

如果你的版本號背後已經有東西在記錄誰改了哪個欄位、何時改的，就不需要。QueryChart 的變更日誌會為每一次修改自動做到這一點，比較版本則把兩個版本並排顯示並標出差異，所以手動維護的 changelog 只是重複平台已經做好的工作。見 /features/version-control。