這里列出了若干在使用版本控制的過程中容易出現的常見問題，這些問題來自實際
工作中的切身體會。但是，這個問題列表未必全面，并且對于具體個人而言，其情形也不盡相同。每個使用版本控制的開發人員的心里可能都有一個類似這樣的列表，并且在實際開發中，或許這個列表還會得到擴充，不斷完善。
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 SourceSafe，這里列出幾個主要的基本概念。
A.1 項目（Project）
版本控制的一個單位，包含若干不同類型的文件。其下所屬代碼及相關文檔，以目錄結構分別存放。一個軟件可以對應一個或多個項目，視情況而定。
A.2 工作目錄（Working Folder）
開發人員對項目文件進行調試修改的地方，一般位于本地機器上。開發人員簽出（checkout）項目中的文件時，將被拷貝到工作目錄下，當修改完文件后，開發人員再將文件從工作目錄簽入（checkin）服務器。
相關鏈接：
沒有使用版本控制的黑暗時代——版本控制心得（一）
版本控制之我見——版本控制心得（二）