沒有使用版本控制的黑暗時代——版本控制心得
來源： morningspace.51.net
作者： 晨光（Morning）
在沒有使用版本控制的開發團體中，我所熟悉的一種常用開發方式是：多個開發人員共同負責一個軟件的開發，每個人在各自的機器上有整個軟件的拷貝，并對之實施編碼，分別完成各自任務之后，再通過文本比對工具將各自機器上的不同版本的軟件整合到一臺機器上。
本文就這樣的開發方式，提出在軟件開發中出現的幾個和版本控制密切相關的典型問題（但未必全面），同樣也是需要通過版本控制來解決的問題，它們來源于實際開發過程中的切身體會，并經過總結和整理。
1 軟件代碼的一致性
軟件的開發、維護和升級，往往是多個人共同協作的過程。不同人對同一個軟件的不同部分同時做著修改，這種行為有時會出現彼此交叉的情況。由于同一軟件在各自開發人員的機器上都有拷貝，軟件的全部代碼都暴露在每個開發人員面前，原則上他有權限可以不加限制地更改軟件的任何部分。而當他們修改的內容屬于公共部分，或者需要被其他人員所負責的部分調用時（軟件各模塊間的彼此依賴關系決定了這種情況是經常發生的），這種修改就屬于交叉情況。此時，就有可能出現代碼的不一致現象。比如：修改者在改動了某個公共函數的同時也修改了其調用接口，若其他人員沒有得知此事，而在各自機器上仍調用原來版本的函數，則當整合時，就會出現錯誤。另一種更為嚴重的情況是，修改者決定廢棄原有函數而另外編寫一個新的函數，但他并未刪除原有函數，這種情況即使最后的整合也可能不會被察覺，如果將這種一致性錯誤的糾正延遲到測試階段，則會增加調試的難度，從而降低開發效率。為了始終保證代碼的一致性，一種解決辦法是，要求修改者每次修改后都通過某種方式告知同組其他人員，或者隨時對軟件做整合。但是這樣，一方面會增加開發人員的負擔，另一方面也降低了軟件的開發效率。
2 軟件內容的冗余問題
軟件在各自開發人員的機器上都有拷貝，并且同一個開發人員在不同時期也會在本機保留當時的軟件版本，也就是說，一臺機器上還可能不止一個版本。這類似于一種信息的冗余。對于不同版本而言，其差別有時可能并不很大，如果說不必要的占用存儲空間是一個次要問題的話，那么另一個問題可能更重要。隨著時間的推移，開發人員可能對自己機器上的不同版本間具體差異的了解變得模糊不情，甚至忘記了當時為什么區分這些版本的原因，這會給整合帶來麻煩。而且，如果需要同時維護多個版本，則對某個版本的改動可能需要反映到其余版本的對應處，很難保證這一過程不會出差錯。還有一點，作為開發人員，有時即使知道自己機器上軟件的某個版本可能不會再使用了，他也不會去刪除（生怕萬一需要從那里獲取點什么），但是通常也不會再去維護或查看它，因此久而久之，這種“僵死之物”會在多臺機器上“蔓延”。
3 軟件過程的“事務性”
對于軟件的某個版本，如果開發人員想要為其增添新的功能，或改善原有功能，而又擔心會攪亂原來運行良好的軟件。一種常用的辦法，就是保留現有版本，另復制一個新的拷貝，并在新的副本上進行修改。這類似于一種事務處理，當將一系列操作做為一個事務時，如果中間某個操作出現偏差，則希望恢復到執行事務之前的狀況。而當完成修改之后，開發人員該如何處理這兩個副本呢？是在新的副本上繼續新的開發，將之作為最新版本；還是將新的改動加入原有版本，刪除新的副本。無論怎樣，都可能會出現如下情況：如果軟件運行正常，則出現2中提到的冗余情況；當刪除修改前的版本后，又發現改動中有問題，但已無法恢復了；改動無誤，將改動加入原有版本時，可能出現人為錯誤，導致軟件運行出錯；即使沒有人為錯誤，這種做法也會給開發人員增加額外負擔，一定程度的降低開發效率。重復上述過程則會出現多個類似的副本，此時，如何對待這些不同版本，將是開發人員需要面對的問題。而如果調試的過程中，發現確實有必要恢復到上一個版本，甚至上上個版本……，此時就不得不保留所有版本了。
4 軟件開發的“并發性”
由于是多人共同開發一個軟件，期間出現多人修改軟件的同一部分，尤其是同時修改，有時是不可避免的。對于前者，具有良好編程習慣的人員的一種通常做法是，對他人的源程序進行修改時添加必要的注釋，寫明修改人，修改原因，修改日期等。但實際情況是，當修改內容很零散或修改過程很復雜時，注釋很難寫，或者代碼被注釋分割得支離破碎影響正常閱讀，或者注釋無法詳細說明實際情況。而且，這種做法也增加了開發人員的負擔：他需要在考慮代碼邏輯的同時，兼顧如何寫注釋；而對于注釋和代碼的一致性也是他需要隨時留意的問題，不能疏忽。因此，我認為這種措施在實際開發中，并未取得實質效果，是不必要的，事實上代碼本身（而非注釋）是最能說明問題的，而修改的記錄應該置于代碼之外的某處。而且，不論是否是同時修改，都需要考慮1所提到的一致性問題，需要及時進行人工的差異比較和整合以便形成一個統一的新版本。
5 軟件代碼的安全性
由于代碼完全暴露于所有開發人員面前，任何人都可以增、刪、改之。除了會造成1所提到的不一致問題外，從安全的角度來看，也是存在隱患的，這一點對于一個自主產權的長期開發的產品而言更是如此。即使是一般的項目開發，不同的人員其分工不同，允許別人可以不加限制地任意修改自己負責模塊的代碼（相當于所有人員都具有管理員身份），總是容易產生問題。對于共有模塊更是如此，所有人都可以修改，一旦修改，則波及全體。
6 軟件的整合
在軟件的整合過程中，一般比較可靠的做法是使用文本比對工具輔助完成的。這種措施，有以下缺點：
可靠性，整合中的人為錯誤會影響軟件的可靠性，有時這種錯誤很難察覺，可能編譯沒有問題，而在測試時卻發現了問題。這種潛在的錯誤發現的時間越晚就越難以糾正。
效率，對于純手工的整合即使熟練操作的人也是需要時間來完成的，而有些整合只是將兩段代碼拼接在一起，這一過程完全可以借助于某些自動機制。這可以大大節省時間，使開發人員可以專注于后續的開發任務。
對于一個采用版本控制進行軟件開發的多人開發團隊而言，其一般的開發方式是：采用服務器/客戶端的形式，在上面分別安裝版本控制工具的服務器和客戶端版本，軟件放在服務器上為大家所共享，開發人員在客戶端從服務器上將軟件的相關部分下載到本地，進行修改，改動結果最終提交到服務器上。
1 軟件版本控制的主要功能和主要特點
版本控制的功能：跟蹤記錄整個軟件的開發過程，包括軟件本身和相關文檔（所帶來的結果是：可標識不同階段的軟件及相關文檔，進行差別分析；對軟件進行可撤消的修改；便于匯總不同人員所做的修改），輔助協調和管理軟件開發團隊。
我認為，對于軟件的版本控制而言，其主要特點包括如下：
1.1 空間上集中統一管理
由于采用服務器/客戶端方式，盡管開發人員可以在自己的本地留有備份，但最終唯一有效的只有服務器端的那個原始拷貝。一定程度可以解決一致性問題、冗余問題。[1]
1.2 時間上全程跟蹤記錄
工具將會自動記錄每個更改細節，和不同時期的不同版本。一定程度可以解決冗余問題、事務性問題、并發性問題。[1]
1.3 操作權限控制
對于不同開發人員，對軟件的不同部分可以定義不同的訪問權限。一定程度可以解決安全性問題。[1]
1.4 自動或半自動
由于有工具輔助控制，可以減輕開發人員的負擔，節省時間，同時降低人為錯誤。像軟件整合這樣的工作，其工作量可以相對減輕。[1]
2 軟件版本控制評價標準
我認為，對軟件進行版本控制，衡量其效果的標準，歸根結底有兩點：效率和質量。如果版本控制最終使軟件開發效率得到提高、使軟件質量得到提升，那就是成功的，反之則是失敗的。效率的提高比較容易理解，質量的提升則體現在：軟件的一致性、冗余程度等。需要指出的是，單就版本控制工具本身并不能保證這兩點。對工具不熟悉或錯誤的使用，以及開發人員的不良習慣等都將導致失敗。有時可能反而降低效率。
3 幾個重要觀點
3.1 版本控制包括代碼和文檔
我認為，廣義的版本控制也應該包括和代碼相關的其他內容，主要指文檔。雖然文檔的一致性問題并不像代碼那么突出，多人同時修改一個文檔的情況一般較為少見，但將文檔只留一個服務器拷貝，會便于集中管理，減少冗余，加上工具的全程跟蹤記錄，可以隨時查看不同時期文檔的內容，相互比對。
3.2 版本控制管理應該包括工具軟件的使用和人為規范的遵循
在版本控制中，人的因素更為重要，規范的行為可以避免很多意想不到的后果，和錯誤使用工具所引起的問題。單純依賴工具，并不能取得良好效果。沒有版本控制的意識、對工具的使用不熟悉（一些功能不知道怎么用，一些功能使用錯誤）、人為的不良習慣，都可能導致錯誤。因此需要使用版本控制工具的開發人員具有自覺良好的意識和習慣，也需要一些相關的規范和制度的保證。
3.3 不能忽略版本控制管理員這一角色的重要性
可以不必單獨劃定一人來擔任這個角色，但如果沒有這一角色的存在，任何人都可以任意操作服務器上已納入版本控制的軟件以及版本控制工具的配置信息（比如用戶權限信息），或者說任何人都可以做管理員，則又會出現安全性問題。從某種程度上講，這和沒有版本控制下每臺機器上都有若干軟件版本的情況是等效的。
3.4 向版本控制過渡是一個循序漸進的、持久的過程
對于一個團隊而言，向版本控制過渡，需要有一個逐步轉變的過程。這包括：制訂一系列合理的循序漸進的措施，使版本控制的意識逐步得到大家的認可，使人員逐漸養成良好習慣（習慣于這種開發方式）。這是一個持久的過程，需要堅持。
這里列出了若干在使用版本控制的過程中容易出現的常見問題，這些問題來自實際工作中的切身體會。但是，這個問題列表未必全面，并且對于具體個人而言，其情形也不盡相同。每個使用版本控制的開發人員的心里可能都有一個類似這樣的列表，并且在實際開發中，或許這個列表還會得到擴充，不斷完善。
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）服務器。
文章來源于領測軟件測試網 http://www.kjueaiud.com/