文件版本控制最佳做法
給已經有編號方案的團隊：文件版本控制最佳做法——保持方案穩定、固定版本／日期／審批人出現的位置、杜絕並行編輯現行副本，並記錄每一次沒有變更的檢討。
運作方式
一旦真實文件依賴於它，就凍結編號方案
把方案本身的改動——由整數改成語意化版本編號、或者重新定義小數的意思——當成一個項目，不是一次微調：它會令每一份既有的交叉引用、培訓紀錄與過往審計引用全部失效。如果發現一個缺陷，就把例外向前記錄下來，而不是為整個檔案庫重新編號。
把版本、日期與審批人放在每個範本的同一個固定位置
選定一個位置——頁首或頁尾——並把它烙進文件範本，令每一位作者都不用另外決定就照用。一個只活在檔案名稱或文件屬性裡的版本號，撐不過列印、截圖或電郵轉發；印在頁面上的可以。
給「現行」版本一套鎖定或簽出慣例
決定同一時間可以有誰把現行版本打開來編輯，以及第二位作者如何得知已經有人在編輯——登記冊裡的一個簽出標記、一個鎖定的檔案，或者一份單一、正式的即時副本，一次只有一個儲存能夠生效。沒有這個，兩次已批准的編輯同時落在同一個版本上，不是一個假設情況。
在第一份文件用得着之前，先寫下大改對小改的規則
在定義編號方案的同一份文件裡，準確訂明甚麼觸發整數躍升——單是正式審批，還是審批加上大幅改寫。一個逐一個案決定這件事的團隊，最終會有兩份不同文件都叫做版本 2.0。
記錄每一次定期檢討，包括甚麼都沒改的那些
給檢討這一步一個「決策」形狀，並附一個標籤為「無變更」的出口，寫入登記冊一條有日期的項目，就像「發布後是否有變更要求？」到達「現行版本維持生效」，而不是甚麼都不做。一條缺失的項目，應該代表檢討沒有發生，而不是代表檢討期間甚麼都沒發生。
讓單一份正式的即時副本，徹底移除鎖定問題
把文件開成一張 QueryChart 圖表，而不是一組靠電郵傳來傳去的檔案，就只有一個現行版本可以編輯——每一次儲存都會自動被捕捉為變更日誌裡的一條新項目，所以簽出慣例已經沒有甚麼需要執行。見 /features/version-control。
常見問題
文件版本控制最應該避免的單一最大錯誤是甚麼？
把方案當成只到有人找到理由改動它為止的暫定安排。重新編號一個既有的檔案庫——即使是為了修正一個真實的缺陷——會弄斷每一份引用過舊編號的交叉引用、培訓紀錄與審計引用，而這個代價幾乎總是高過忍受一套不完美方案的代價。以一項有記錄的例外，向前解決問題，而不是去改動已經發放的東西。
如何阻止兩個人同時編輯同一份「現行」版本？
要麼加一套明確的簽出慣例——登記冊裡的一個標記，顯示誰正在打開這份文件，讓第二位作者知道要等——要麼從結構上移除這個可能性，只保留單一份正式的即時副本，而不是靠電郵或共用磁碟傳遞的檔案。QueryChart 做的是後者：每一份文件都是一張即時圖表，每一次儲存都自動變成一個版本，沒有第二份副本可以分岔。見 /features/version-control。
甚麼應該算大改，甚麼算小改？
沒有一條放諸四海皆準的規則，這正是為甚麼它必須在第一份文件用得着之前寫下來，而不是逐一個案判斷。一個常見的慣例，是把整數的大改躍升，單純繫於正式審批——期間任何一次草稿修訂，無論多實質，都維持小數——這樣「這次改動有多大」，就永遠不用在配給版本號那一刻才拿出來爭論。
一次沒有發現需要變更的定期檢討，需要記錄嗎？
需要——一次沒有記錄的檢討，跟一次從未發生過的檢討沒有分別。給你流程裡的檢討步驟一個「決策」形狀，並附一個標籤為「不需要變更」的出口，仍然向登記冊寫入一條有日期的項目，就像一列決策記錄它所走的每一條分支，不只是那些通向新地方的分支。