引言：

若是還有能夠毫無偏見地涉及各個編程語言。比源碼管理軟件更必要的工具。我倒是非常想見識一下。

源碼管理軟件是我們工作的必備工具，是很多開發團隊的血液。

那為什麽我們都會對它有所誤解呢？為什麽都非常難理解版本號控制系統的核心價值和基本原理呢？

　原文作者總結出10條慣例（假設你願意也能夠用“戒律”）意味著必須服從它，並且一開始非常難理解。

它們與全部類型編程語言的版本號控制軟件都有關聯。在這裏我選取了Subversion和.NET的幾個樣例，只是它們也廣泛地適用於其它的一些技術。

英文原文：The 10 commandments of good source control management

　　第一誡、假設你如今還在使用VSS，請立馬停手

　　它已經死了。

當然不全然對。它也存活了很多年，被全新的更有用的源碼管理工具超越之後還在茍延殘喘地活著。

準確地說當微軟(還是會堅持一段時間的)，它才是真的死了。

　　平心而論。VSS還是一個不錯的工具。

在1995年，它的光芒被像Subversion這樣類似於Git和Mercurial的分布式軟件給遮蓋住了。

微軟表示要代替它已經好多年了。

　　原因是由於不支持現在的標準所導致的一系列缺陷使它一直不被看好。

眾所周知它是微軟的悲劇系統，但不知何故它能堅持這麽久。雖然它有那麽多小故障，缺陷，而且不包括必需的功能（相對於今天的標準）。

　　第二誡、假設代碼沒放在源碼管理軟件裏。等於它不存在

　　每天反復讀這句話——“使用源碼管理軟件是唯一的有效措施”。除非你在工作時使用項目的源碼管理庫來控制代碼版本號——否則代碼等於沒有存在過。

　　顯然你曾發覺在你的本地機器上執行良好的代碼在其它人那裏執行的效果並不理想。是不是？他們不能獲取你的最新版本號，他們沒法去合並代碼文件，你沒有正確地部署它（參考you‘re deploying it wrong）並且假設你的SSD硬盤壞了的話，你將永遠地失去你的勞動成果。

　　僅僅要你保持這個心態——代碼僅僅有提交後才是真的安全。才是其它良好編程習慣的保障。你能夠把你的任務劃分成很多非常小的單元以便你逐一提交。

你須要頻繁地這麽做。你就不必操心你的硬件會不會出棘手問題。

　　只是更重要的意義是（至少對於你的團隊領導來說），通過源碼管理軟件能夠看到你做了什麽。使用圖表並列出項目清單是個好方法。只是怎麽知道他們實際上在做些什麽？而使用源碼管理軟件進行工作就能看得一清二楚了。

　　第三誡、要早提交。常提交。而且不要認為麻煩

　　關於前面那點，避免“幻影代碼”（就是僅僅能在你的機器上看到的代碼）的唯一方法是常常提交你的任務而且不要認為麻煩。

它能夠解決你的問題，只是這樣做也會對你的工作產生其它的影響：

　　1. 每一個提交的修訂都會為你提供一個還原點。假設你全然把代碼搞砸了（沒騙你，我們都這麽做過）。你是希望恢復到一個小時前的工作還是一周前的工作？

　　2. 合並文件時會出現的危急會隨著時間不斷添加。合並文件一直非常麻煩。

假設你不是每天都保持提交代碼，某一天你會突然發現你和其它人的更改內容會有50多個沖突。你不會為此感到高興的。

　　3. 它促使你把任務分離成分散的單元。通常人們都是快完畢的時候才提交的，由於他們想把代碼做成一個完整的邏輯單元模塊。只是龐大的任務不可避免地要分離出較小的分散功能。而頻繁地提交它們會使你更了解它們。你能夠一個個地構建並提交。

　　假設你做到這些，你的提交歷史不可避免地開始類似於一種半規律的樣式，裏面每一個工作日都是在提交任務。當然不總是這樣。也有停下來重構或測試，或者其它合理的活動也會中斷標準的開發周期。

　　然而。當我在看一個獨立的——尤其是完整的項目時，每當發現我們在一個標準的開發周期裏。有一天或幾天什麽都沒有做，我便會很擔憂。我之所以擔憂是由於這意味著什麽地方出問題了。一般不是有人正在想方設法要把問題搞定的話，就是由於卡在某個問題上而導致項目全然沒有進度。不管究竟是什麽情況，源碼管理軟件都會告訴你出現故障了。

　　第四誡、提交前要檢查你更改了什麽

　　往源碼管理軟件裏提交代碼的步驟事實上很easy（你恐怕會困惑上一條為什麽說的那麽麻煩）。一般僅僅要發現文件內容有變更時都會不顧後果地把文件傳上去。像這樣——“我的項目根文件夾下有文件內容變更了，我要快點提交上去！”

　　如此會發生一件（或兩件）事情：首先，程序猿會沒有意識地把文件夾下的垃圾代碼文件也上傳上去。一些人看到類似以下的窗體時，就會點擊“選擇所有”然後提交——這樣源倉庫裏就會被本不應該存在的未調試的文件和其它垃圾文件給弄亂。

　　或者是，程序猿實際上並沒有檢查他們更改過什麽就把文件上傳了。

當你在工作中處理配置文件或項目定義文件時非常easy就不經意把那些不想提交的文件給上傳了，並且那些文件非常可能就被別的程序猿用到了。

你真的會記住你在配置文件中的全部更改嗎？

　　解決方法非常easy：你必須在提交前立馬檢查你改過什麽地方。做起來事實上比聽起來還要easy。

使用很多系統已經提供的“忽略”特性能夠大幅度地減輕“不經意上傳文件”的危急。

你能夠忽略Thumbs.db文件由於你壓根不想上傳它。

你在每次修訂後可能還有其它文件不想上傳——那麽就忽略掉它們吧！

　　至於文件中的更改，你通常能夠使用某個流行的文本比較工具來觀察差異。為什麽我又要上傳一次Web.config文件呢？

　　噢，我想起來了，我想把嘗試password失敗的最大次數從5次降低到3次。

啊，我差點沒註意把一個虛擬的登錄頁面給上傳上去了。這樣的在提交前做檢查的練習能夠讓你更easy理解下一節的內容。

　　第五誡、寫提交信息時一定要認真

　　這是一個古老的諺語（出處不詳），大意是說“寫每一條提交信息時就好象等下會讀到它的人是一個斧頭殺人狂，並且他還知道你住在哪裏”。假設我是那個殺人狂並在研究你的代碼想追蹤bug的話。看到的提交信息所有都是“代碼更新了”，小心，我會來砍你的！

　　我的解決的方法就是解釋清楚為什麽要提交新的代碼。

每次你對代碼進行更改都是有原因的。可能什麽地方會崩潰。

可能客戶不喜歡如今的主題顏色。

可能你只要調整一下構建配置。不管是什麽。這都是有原因的並且你要把原因用文字保留下來。

　　為什麽？這樣做的原因有非常多。並且在不同環境下各不同樣。舉個樣例。使用“歸屬”特性或其它類似的功能顯示出誰改了代碼那些地方。假設我不記得18個月之前我對項目的Web.config文件改過什麽地方或者我為什麽要修改應用程序的設置，是由於我沒有在當時留下一個適當的提交信息，而如今會非常easy：

　　這是一個能夠隨時觀察代碼更改的軟件的一種。不管我像以下那樣想了解一個文件的完整更改歷史，還是僅僅想知道團隊昨天做了什麽，留下一個描寫敘述性的相關記錄意味著僅僅要不經意一瞥就能知道是什麽情況了。

　　最後強調一下。當調試遇到錯誤時提交信息的重要性是無法預計的。舉個樣例，在你的集成環境裏的最後更新的地方能夠找到出錯的原因。我的樣例是非常顯而易見的，只是把信息表示出來能夠把非常多棘手的問題變得極好解決。

　　把這條牢記於心。這裏列出一些提交信息的反面教材：

　　1. 可惡
　　2. 能跑了
　　3. 攻克了一些混帳問題
　　4. 攻克了
　　5. 改進了一點bug
　　6. 上傳了
　　7. 排字錯誤
　　8. 修訂1024

　　好的，我從Stack Overflow站點的哪些是你寫過的最差勁的提交信息（譯者註：帖子已經被刪除了，原因難道是出現了臟話？）帖子裏選取了以上內容，只是它們和我曾經看過的提交信息並不同樣。

它們沒有告訴你有關代碼更改的不論什麽有效信息。它們都是垃圾信息。

　　關於提交信息最後要註意的是；同一個程序猿之後提交信息絕不能和前面的全然同樣。原因非常好理解：你向源碼管理軟件提交文件是由於對於上一個版本號的代碼有東西改變了。你如今的代碼和之前的已經不一樣了，假設你的提交信息是完整準確的。理論上就不能和前面的同樣。假設是同樣的（可能有時真的會這樣）。日誌就會難以閱讀。由於沒有辦法區分兩條提交有什麽差別。

　　第六誡、你必須自己提交你的更改內容——不能托付他人

　　聽起來非常奇怪。但它的確會發生，我看過不止一次。近期的是上周。

情況是這種，源碼庫被視為極高的地位。

由於非常多原因。團隊會去追求完美代碼的潔凈和單一。為了保持這種神聖的狀態，代碼僅僅能由某個領頭的程序猿來提交。他在提交前會小心地整合，審查並（大概會）調整改善代碼。

　　即使站在非常遠也能非常easy評價這個方法。不太頻繁的提交（可能一周幾次）。僅僅有一個脫離團隊其它程序猿的人來提交，並且不可避免地在這段漫長的無提交時期裏會有人的工作會導致項目混亂。

非常非常不好。

　　這樣做會有兩個錯誤：首先，源碼管理軟件並不意味著它裏面代碼是神聖不可侵犯的。至少在整個開發周期裏是這種。它應該是團隊頻繁整合文件，在出錯時還原到正常而且共同解決這個問題的地方。不是自始至終都要這樣做，僅僅有在應用程序周期的公布時期為了達到某種狀態時才做的。

　　還有一個問題——而且真的是極為關鍵的——站在程序猿的視角。這樣等於你壓根沒有在用源碼管理軟件！它等於沒有同伴之間的代碼整合，沒有還原。提交信息沒有負責人，什麽都沒有！

你們不過在自己的象牙塔裏各自寫各自的代碼然後等著未來順便某一天把它交給領導就完事了。

　　不要這樣做。千萬不要。

　　第七誡、一定要管理好數據庫的版本號

　　這一點是我們都知道必需要做的，可是非常多人認為它麻煩。

問題是非常多（或者是大部分）應用程序沒了數據庫就不能執行。假設你沒有管理好數據庫，那你實際上做的就是一個不完整的全然沒用的應用程序。

　　差點兒全部的版本號控制系統的工作就是管理好文件系統內的文件。它僅僅是對像HTML頁面。圖片，CSS。項目配置文件和其它在文件系統的獨立單元這類典型應用作用較大。問題是它確實沒法在與程序有關聯的數據庫上起到作用。你總不能替換掉龐大的數據庫，把全部舊數據文件和包括一大堆對象和數據日誌文件統統換掉。這樣會讓版本號控制系統全然亂成一堆。

　　Red Gate公司開發的智能的SQL Source Control使這個情況得到了合理解決。我在去年寫的Rocking your SQL Source Control world with Red Gate這篇帖子裏具體說明了這款軟件，所以我如今就不多說了；總之就是數據庫管理如今會很easy了！

　　老實說，假設你沒有管理好你的數據庫版本號。你的開發會伴隨著非常大的問題。

在更改數據庫的時候沒有源碼的管理。沒有還原點。而且非常難和團隊密切合作。使用數據庫版本號控制系統能夠使開發更輕松。

　　第八誡、編譯生成的文件不要放進源碼管理軟件裏

　　簡單地說：在編譯執行項目時自己主動生成的結果文件不要放進源碼管理軟件裏。對於.Net開發的程序猿，主要是"bin"和"obj"目錄裏一般會出現的.dll和.pdb文件。

　　為什麽？由於假設你這樣做，你的同事會恨你的。

這意味著每當他們從版本號控制系統裏取下最新文件時會讓你的編譯文件覆蓋掉他們的。這是一個雙重噩夢（你絕不能這樣做）。在他們下一次編譯時就會出問題。並且僅僅要他們又一次編譯後再把編譯文件又一次上傳上去，相同的問題會以相反的方向再發生一次，只是這次你是受害者。你肯定不想這種。

　　當然還有一個問題就是這樣做非常浪費。這會浪費源碼管理server的硬盤空間。會浪費帶寬並會通過網絡發送時一直潛伏著，並且這樣做造成的不可避免的沖突會極度浪費你的時間。

　　所以我們繼續使用之前提到的“忽略”方案。僅僅要把像"bin"和"obj"這種路徑直接忽略掉，一切就真的非常輕松了。僅僅要依照這個方案做一次。全部人都會感到開心的。

　　事實上我在寫pre-commit hooks時就說到了在版本號控制的server上不能提交此類文件。當然假設有值得這麽做的原因的話，僅僅有這樣的情況下你能夠上傳。只是我傾向於不要這麽做以免將來會導致某個人在更新時發生沖突。

　　第九誡、不要上傳你自己的用戶設置

　　老實說，我覺得非常多人沒有註意到他們把自己的私人設置文件上傳到源碼管理軟件裏了。

這樣會出現的問題是：很多工具會產生僅僅管理你自己本地配置的文件。它們僅僅對你實用並且通常和其它人的私人設置文件相異。假設你把它們上傳到源碼管理軟件裏，非常快你就會覆蓋掉其它人的私人設置文件。這樣並不好。

　　這是一個典型的.NET程序的樣例：

　　假如你沒有立馬清理的話。多余出來的就是擴展文件和類型描寫敘述，也就是.ReSharper.user文件和.suo（Solution User Option， 解決方式用戶選項）兩個文件。它們僅僅屬於你，對其它人無效。

　　為了理解這點，我們來看看ReSharper文件：

<Configuration>
  <SettingsComponent>
    <string />
    <integer />
    <boolean>
      <setting name="SolutionAnalysisEnabled">True</setting>
    </boolean>
  </SettingsComponent>
  <RecentFiles>
    <RecentFiles>
      <File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Web.config" 
caret="1121" fromTop="26" />
      <File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Site.Master.cs" 
caret="0" fromTop="0" />

　　在這個樣例裏。不過在用戶文件中記錄了我啟動了解決方式分析功能。

這不過針對我，我喜歡這個功能，其它人則不一定。

通常由於他們用的是老化的廉價的機子，我有點跑題了。

關鍵是我的設置會強制讓其它人也運行。

我這麽做不代表其它人也要這麽做。

　　（旁註：VSS不完美的地方主要在於ignoring .ReSharper.user files is a bit of a problem。能夠看看這篇帖子）

　　這個原理相同也適用於.suo文件。只是這裏看不到裏面的內容（它不是XML格式，而是二進制）。這個文件記錄了解決方式瀏覽器的狀態。公布設置和其它一些你不讓強制用在其它人電腦的東西。

　　所以我們要再次使用忽略方案來處理。

前提你如今用的不是VSS。

　　第十誡、附屬文件也要集成在一起

　　這是十誡中的最後一條也是最最重要的一條。當應用程序須要外部的附屬文件存在才幹夠正常執行的話，把那些文件也都放進源碼管理軟件裏！人們傾向於犯的錯誤是，在他們擁有自己設置文件和本地附屬文件的環境裏一切都表現得非常好就把東西都上傳了。之後認為沒問題了就無論了。可是其它人不能從源碼庫裏找到相同的附屬文件的話。全部東西都會悲劇性地報錯。

　　我想到這點是由於今天從源碼庫裏拖出某個舊項目並執行它時出現了這種畫面：

　　我以為NUnit一直在機器上，但這次沒有。

幸運的是使用NuGet能夠高速解決這個問題，可是沒有附屬文件的話。不是每次都能夠用相同的方式就能輕松解決的。

有些情況下，它們並非公開的。你非常難所有都獲取到。

　　我從源碼管理軟件裏取出的項目執行時之所以會報錯是由於我發現"C:\Program Files..."路徑下丟失了附屬的文件。

我花了不少時間用來聯系最後更改過它的那個人（非常明顯他在世界上還有一個非常遠的地方），獲取了那個文件，把它放進"Libraries"目錄下並把它上傳到了版本號控制系統裏，這樣下一個提取文件的人就不須要再這麽麻煩了。

　　當然還有一個重要的原因是。假設你在不論什麽一種集成環境裏工作時，你的構建server不一定安裝了那些庫。你必須有那些文件才幹執行。Doug Rathbone近期寫了一篇非常好的關於這點的文章Third party tools live in your source control(源碼管理軟件裏的第三方工具)。並非非要那樣做（我們也善意地評價了效果），只是它確實是一個非常方便的建議。

　　因此推薦每一個人第一天就把程序執行所須要的東西全都放進版本號控制系統裏。

　　小結：

　　沒有哪一條是非常難理解的。老實說。它們都非常基礎：盡快並頻繁地提交，確認你提交的東西改了什麽。還有東西一定要放進版本號控制系統裏。解釋清楚你的提交信息和確保是你自己提交的，不要忘記數據庫和不要忘記附屬文件。還有就是不要使用VSS:)

總結：

源碼的科學有序管理，不論是對於個人還是團隊還說都是極具價值的一件事情。如此重要的事情，我們該用什麽工具來管理呢？請見一篇博客：《SVN—TFS，雷鐘意bingo多點？》

談談源碼管理那點事兒（一）——源碼管理十誡（轉）