我總結出10條慣例——如果你願意也可以用“戒律”——意味着必須服從它而且從一開始很難去了解。它們與所有類型程式設計語言的版本控制軟體都有關聯。在這裡我選取了Subversion和.NET的幾個例子，不過它們也廣泛地适用于其他的一些技術。
第一誡.如果你現在還在使用VSS－請立刻停手
平心而論，VSS還是一個不錯的工具。在1995年，它的光芒被像Subversion這樣類似于Git和Mercurial的分布式軟體給遮蓋住了。微軟表示要取代它已經好多年了。
第二誡.如果代碼沒放在源代碼管理軟體裡，等于它不存在
每天重複讀這句話——“使用源代碼管理軟體是唯一的有效措施”。除非你在工作時使用項目的源代碼管理庫來控制代碼版本——否則代碼等于沒有存在過。
隻要你保持這個心态——代碼隻有送出後才是真的安全，才是其他良好程式設計習慣的保障。你可以把你的任務劃分成許多很小的單元以便你逐一送出。你需要頻繁地這麼做。你就不必擔心你的硬體會不會出棘手問題。
不過更重要的意義是（至少對于你的團隊上司來說），通過源代碼管理軟體可以看到你做了什麼。使用圖表并列出項目清單是個好方法，不過怎麼知道他們實際上在做些什麼？而使用源代碼管理軟體進行工作就能看得一清二楚了。
第三誡.要早送出，常送出，并且不要覺得麻煩
關于前面那點，避免“幻影代碼”（就是隻能在你的機器上看到的代碼）的唯一方法是經常送出你的任務并且不要覺得麻煩。它可以解決你的問題，不過這樣做也會對你的工作産生其他的影響：
1.每個送出的修訂都會為你提供一個還原點。如果你完全把代碼搞砸了（沒騙你，我們都這麼做過），你是希望恢複到一個小時前的工作還是一周前的工作？
2.歸并檔案時會出現的危險會随着時間不斷增加。歸并檔案一直很麻煩。如果你不是每天都保持送出代碼，某一天你會突然發現你和其他人的更改内容會有50多個沖突。你不會為此感到高興的。
3.它促使你把任務分離成分散的單元。通常人們都是快完成的時候才送出的，因為他們想把代碼做成一個完整的邏輯單元子產品。不過龐大的任務不可避免地要分離出較小的分散功能，而頻繁地送出它們會使你更了解它們，你可以一個個地建構并送出。
第四誡.送出前要檢查你更改了什麼
往源代碼管理軟體裡送出代碼的步驟其實非常簡單。（你恐怕會困惑上一條為什麼說的那麼麻煩。）一般隻要發現檔案内容有變更時都會不顧後果地把檔案傳上去。像這樣——“我的項目根目錄下有檔案内容變更了，我要快點送出上去！”
或者是，程式員實際上并沒有檢查他們更改過什麼就把檔案上傳了。當你在工作中處理配置檔案或項目定義檔案時很容易就不經意把那些不想送出的檔案給上傳了，而且那些檔案很可能就被别的程式員用到了。你真的會記住你在配置檔案裡的所有更改嗎？
解決方法很簡單：你必須在送出前立刻檢查你改過什麼地方。做起來其實比聽起來還要容易。使用許多系統已經提供的“忽略”特性可以大幅度地減輕“不經意上傳檔案”的危險。你可以忽略Thumbs.db檔案因為你壓根不想上傳它。你在每次修訂後可能還有其他檔案不想上傳——那麼就忽略掉它們吧！
至于檔案裡的更改，你通常可以使用某個流行的文本比較工具來觀察差異。為什麼我又要上傳一次Web.config檔案呢？
噢，我想起來了，我想把嘗試密碼失敗的最大次數從5次減少到3次。啊，我差點沒注意把一個虛拟的登入頁面給上傳上去了。這種在送出前做檢查的練習可以讓你更容易了解下一節的内容。
第五誡.寫送出資訊時一定要認真
這是一個古老的諺語（出處不詳），大意是說“寫每一條送出資訊時就好象等下會讀到它的人是一個斧頭殺人狂，而且他還知道你住在哪裡”。如果我是那個殺人狂并在研究你的代碼想追蹤bug的話，看到的送出資訊全部都是“代碼更新了”，小心，我會來砍你的！
我的解決辦法就是解釋清楚為什麼要送出新的代碼。每次你對代碼進行更改都是有原因的。可能什麼地方會崩潰。可能客戶不喜歡現在的主題顔色。可能你僅僅要調整一下建構配置。無論是什麼，這都是有原因的而且你要把原因用文字保留下來。
為什麼？這樣做的原因有很多，而且在不同環境下各不相同。舉個例子，使用“歸屬”特性或其他類似的功能顯示出誰改了代碼那些地方。如果我不記得18個月之前我對項目的Web.config檔案改過什麼地方或者我為什麼要改動應用程式的設定，是因為我沒有在當時留下一個适當的送出資訊，而現在會非常簡單：
這是一個可以随時觀察代碼更改的軟體的一種。無論我像下面那樣想了解一個檔案的完整更改曆史，還是隻想知道團隊昨天做了什麼，留下一個描述性的相關記錄意味着隻要不經意一瞥就能知道是什麼情況了。
最後強調一下，當調試遇到錯誤時送出資訊的重要性是無法估計的。舉個例子，在你的內建環境裡的最後更新的地方可以找到出錯的原因。我的例子是非常顯而易見的，不過把資訊表示出來可以把很多棘手的問題變得極好解決。
把這條牢記于心，這裡列出一些送出資訊的反面教材：
1.可惡
2.能跑了
3.解決了一些混帳問題
4.解決了
5.改進了一點bug
6.上傳了
7.排字錯誤
8.修訂1024
關于送出資訊最後要注意的是；同一個程式員之後送出資訊絕不能和前面的完全相同。原因很好了解：你向源代碼管理軟體送出檔案是因為對于上一個版本的代碼有東西改變了。你現在的代碼和之前的已經不一樣了，如果你的送出資訊是完整準确的，理論上就不能和前面的相同。如果是相同的（可能有時真的會這樣），日志就會難以閱讀，因為沒有辦法區分兩條送出有什麼差別。
第六誡.你必須自己送出你的更改内容——不能委托他人
聽起來很奇怪，但它的确會發生，我看過不止一次，最近的是上周。情況是這樣的，源代碼庫被視為極高的地位。因為很多原因，團隊會去追求完美代碼的潔淨和單一。為了保持這種神聖的狀态，代碼隻能由某個領頭的程式員來送出，他在送出前會小心地整合，審查并（大概會）調整改善代碼。
即使站在很遠也能很容易評價這個方案。不太頻繁的送出（可能一周幾次），隻有一個脫離團隊其他程式員的人來送出，而且不可避免地在這段漫長的無送出時期裡會有人的工作會導緻項目混亂。非常非常不好。
這樣做會有兩個錯誤：首先，源代碼管理軟體并不意味着它裡面代碼是神聖不可侵犯的；至少在整個開發周期裡是這樣的。它應該是團隊頻繁整合檔案，在出錯時還原到正常并且共同解決問題的地方。不是自始至終都要這樣做，隻有在應用程式周期的釋出時期為了達到某種狀态時才做的。
另一個問題——并且真的是極為關鍵的——站在程式員的視角，這樣等于你壓根沒有在用源代碼管理軟體！它等于沒有同伴之間的代碼整合，沒有還原，送出資訊沒有負責人，什麼都沒有！你們僅僅是在自己的象牙塔裡各自寫各自的代碼然後等着未來順便某一天把它交給上司就完事了。
不要這樣做。千萬不要。
第七誡.一定要管理好資料庫的版本
這一點是我們都知道必須要做的，但是很多人覺得它麻煩。問題是很多（或者是大部分）應用程式沒了資料庫就不能運作。如果你沒有管理好資料庫，那你實際上做的就是一個不完整的完全無用的應用程式。
幾乎所有的版本控制系統的工作就是管理好檔案系統内的檔案。它隻是對像HTML頁面，圖檔，CSS，項目配置檔案和其他在檔案系統的獨立單元這類典型應用作用較大。問題是它确實沒法在與程式有關聯的資料庫上起到作用。你總不能替換掉龐大的資料庫，把所有舊資料檔案和包含一大堆對象和資料日志檔案統統換掉。這樣會讓版本控制系統完全亂成一堆。
老實說，如果你沒有管理好你的資料庫版本，你的開發會伴随着很大的問題。在更改資料庫的時候沒有源代碼的管理，沒有還原點，并且很難和團隊密切合作。使用資料庫版本控制系統可以使開發更輕松。
第八誡.編譯生成的檔案不要放進源代碼管理軟體裡
簡單地說：在編譯運作項目時自動生成的結果檔案不要放進源代碼管理軟體裡。對于.Net開發的程式員，主要是”bin”和”obj”檔案夾裡通常會出現的.dll和.pdb檔案。
為什麼？因為如果你這樣做，你的同僚會恨你的。這意味着每當他們從版本控制系統裡取下最新檔案時會讓你的編譯檔案覆寫掉他們的。這是一個雙重噩夢（你絕不能這樣做），在他們下一次編譯時就會出問題。而且隻要他們重新編譯後再把編譯檔案重新上傳上去，同樣的問題會以相反的方向再發生一次，不過這次你是受害者。你肯定不想這樣的。
當然另一個問題就是這樣做很浪費。這會浪費源代碼管理伺服器的硬碟空間，會浪費帶寬并會通過網絡發送時一直潛伏着，而且這樣做造成的不可避免的沖突會極度浪費你的時間。
是以我們繼續使用之前提到的“忽略”方案。隻要把像”bin”和”obj”這樣的路徑直接忽略掉，一切就真的很輕松了。隻要按照這種方法做一次，所有人都會感到開心的。
第九誡.不要上傳你自己的使用者設定
老實說，我認為很多人沒有注意到他們把自己的私人設定檔案上傳到源代碼管理軟體裡了。這樣會出現的問題是：許多工具會産生隻管理你自己本地配置的檔案。它們隻對你有用而且通常和其他人的私人設定檔案相異。如果你把它們上傳到源代碼管理軟體裡，很快你就會覆寫掉其他人的私人設定檔案。這樣并不好。
這是一個典型的.NET程式的例子：
假如你沒有立刻清理的話，多餘出來的就是擴充檔案和類型描述，也就是.ReSharper.user檔案和.suo（Solution User Option， 解決方案使用者選項）兩個檔案，它們隻屬于你，對其他人無效。
為了了解這點，我們來看看ReSharper檔案：
1
<code><</code><code>code</code><code>>&lt;Configuration&gt; &lt;SettingsComponent&gt; &lt;string /&gt; &lt;integer /&gt; &lt;boolean&gt; &lt;setting name="SolutionAnalysisEnabled"&gt;True&lt;/setting&gt; &lt;/boolean&gt; &lt;/SettingsComponent&gt; &lt;RecentFiles&gt; &lt;RecentFiles&gt; &lt;File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Web.config" caret="1121" fromTop="26" /&gt; &lt;File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Site.Master.cs" caret="0" fromTop="0" /&gt;</</code><code>code</code><code>></code>
在這個例子裡，僅僅是在使用者檔案裡記錄了我啟動了解決方案分析功能。這隻是針對我，我喜歡這個功能，其他人則不一定。通常因為他們用的是老化的便宜的機子，我有點跑題了。關鍵是我的設定會強制讓其他人也執行。我這麼做不代表其他人也要這麼做。
是以我們要再次使用忽略方案來處理。前提你現在用的不是VSS。
第十誡.附屬檔案也要內建在一起
這是十誡中的最後一條也是最最重要的一條。當應用程式需要外部的附屬檔案存在才可以正常運作的話，把那些檔案也都放進源代碼管理軟體裡！人們傾向于犯的錯誤是，在他們擁有自己設定檔案和本地附屬檔案的環境裡一切都表現得很好就把東西都上傳了，之後覺得沒問題了就不管了。但是其他人不能從源代碼庫裡找到同樣的附屬檔案的話，所有東西都會悲劇性地報錯。
我想到這點是因為今天從源代碼庫裡拖出某個舊項目并運作它時出現了這樣的畫面：
我從源代碼管理軟體裡取出的項目運作時之是以會報錯是因為我發現”C:\Program Files…”路徑下丢失了附屬的檔案。我花了不少時間用來聯系最後更改過它的那個人（很明顯他在世界上另一個很遠的地方），擷取了那個檔案，把它放進”Libraries”檔案夾下并把它上傳到了版本控制系統裡，這樣下一個提取檔案的人就不需要再這麼麻煩了。
是以推薦每個人第一天就把程式運作所需要的東西全都放進版本控制系統裡。
總結
沒有哪一條是很難了解的。老實說，它們都很基礎：盡快并頻繁地送出，确認你送出的東西改了什麼，還有東西一定要放進版本控制系統裡，解釋清楚你的送出資訊和確定是你自己送出的，不要忘記資料庫和不要忘記附屬檔案。:)