版本控制常見問題列表——版本控制心得（三） (轉)

版本控制常見問題列表——版本控制心得（三） (轉)[@more@]

　　 這裡列出了若干在使用版本控制的過程中容易出現的常見問題，這些問題來自實際工作中的切身體會。但是，這個問題列表未必全面，並且對於具體個人而言，其情形也不盡相同。每個使用版本控制的開發人員的心裡可能都有一個類似這樣的列表，並且在實際開發中，或許這個列表還會得到擴充，不斷完善。

Item 1. 專案的邏輯結構混亂（這裡的“專案”是版本控制中的術語，見A.1）

　　 這是在實施版本控制過程中一個容易出現的問題，尤其是對於專案開發（此處非術語）。其原因有很多，比如：開始時對需求不明確，導致本身結構混亂，使在定義軟體的邏輯結構時，時常變化。又如：一個團隊中，大家各自都之關心自己負責的模組，每個人各自制定適合自己的邏輯結構，導致最終的專案結構是一個大雜燴（多個結構組合而成）。久而久之，就會導致軟體管理混亂，增加維護負擔，反而降低。結構中，有的目錄可能是“死角”，永遠都沒有使用到；有的目錄可能是重複的，造成冗餘；有的目錄可能大家同時在用，各自對程式碼的修改彼此影響。自始至終合理安排和規劃專案的邏輯結構，這是一定需要堅持的。

Item 2. 多人修改同一個

　　 一旦出現這樣的情況，很有可能某人辛勤勞動的成果，會被別人毀於一旦。其解決辦法是：在一般情況下，確保在任何時刻都只有一個成員對某個特定的檔案進行修改，這樣可以防止檔案被其他成員的修改意外。為了適應多人同時修改同一個檔案的情況，版本控制管理員也可以改變此預設設定以允許對單個檔案同時有多個簽出（checkout），並且仍禁止對他人的修改進行覆蓋。

Item 3. 本地版本和版本不一致

　　 有時會碰到這樣的情形，開發人員在從伺服器那裡更新本地版本時，只更新了部分內容，導致本地編譯不透過。應該時刻注意保持本地版本和伺服器版本的一致性，這是一個認識的問題，因為伺服器版本才是真正唯一有效的。多個員還必須注意不要為了解決同一個問題而浪費時間。對某項功能的實現，由於本地和伺服器的不一致，導致大家重複實現。應該對伺服器端資料的全部內容，包括所有子資料夾，定期進行，這是絕對重要的一項工作。

Item 4. 混亂

　　 對於所有開發人員和各自負責的模組，根據實際情況，制定合理的使用者許可權，哪些人對哪些目錄只有可讀許可權，哪些人對哪些目錄有讀寫許可權。不應該出現所有人都是管理員這樣的極端情況。

Item 5. 手工修改檔案的只讀標記

　　 為了防止你對沒有簽出的檔案進行修改，版本控制管理工具會將這些檔案指定並標明為只讀檔案。當你簽出一個檔案時，只讀標記便被刪去。一種經常出現的不良習慣是，為了圖省事，在沒有簽出檔案時便試圖修改檔案，當發現檔案不能儲存時，便手工修改其只讀標記。這是一切混亂的“源頭”，它將導致不一致、有效內容被覆蓋等問題。

Item 6. 沒有指定工作目錄或存在多個工作目錄

　　 每個開發人員必須擁有一個獨一無二的工作目錄，它不能與任何其他開發人員共享（這裡的“工作目錄”是版本控制中的術語，見A.2）。

Item 7. 頻繁的簽入或很少簽入

　　 掌握好籤入的時間，比如一天，或者在其他人需要的時候。並非每次微小的改動都需要馬上籤入，也並非每改完一個檔案都將其簽入，但也不要忘記簽入。

Item 8. 從伺服器上獲取最近版本時的疏忽

　　 如果選擇獲取當前已經簽出並且已經修改的檔案最新版本，操作時必須非常小心。如果你選擇取代檔案，你將用最近一次簽入的檔案版本改寫你做的修改，這可能會使你所做的工作白費。大多數情況下，最保險的做法是選定Apply To All Items，並選擇Leave。

A 軟體版本控制中出現的幾個主要概念

　　 參考Visual Safe，這裡列出幾個主要的基本概念。

A.1 專案（Project）

　　 版本控制的一個單位，包含若干不同型別的檔案。其下所屬程式碼及相關文件，以目錄結構分別存放。一個軟體可以對應一個或多個專案，視情況而定。

A.2 工作目錄（Working Folder）

　　 開發人員對專案檔案進行修改的地方，一般位於本地機器上。開發人員簽出（checkout）專案中的檔案時，將被複製到工作目錄下，當修改完檔案後，開發人員再將檔案從工作目錄簽入（checkin）伺服器。
(The End)