源代碼管理十誡
若是還有可以毫無偏見地涉及各個編程語言，比源代碼管理軟件更必要的工具，我倒是很想見識一下。源代碼管理軟件是我們工作的必備工具，是許多開發(fā)團隊的血液。那為什么我們都會對它有所誤解呢？為什么都很難理解版本控制系統(tǒng)的核心價值和基本原理呢？
我總結出10條慣例——如果你愿意也可以用“戒律”——意味著必須服從它而且從一開始很難去理解。它們與所有類型編程語言的版本控制軟件都有關聯(lián)。在這里我選取了Subversion和.NET的幾個例子，不過它們也廣泛地適用于其他的一些技術。
***誡.如果你現(xiàn)在還在使用VSS－請立刻停手
它已經(jīng)死了。當然不完全對，它也存活了許多年，被全新的更實用的源代碼管理工具超越之后還在茍延殘喘地活著。準確地說當微軟幾個月后不再為其提供支持時(還是會堅持一段時間的)，它才是真的死了。
平心而論，VSS還是一個不錯的工具。在1995年，它的光芒被像Subversion這樣類似于Git和Mercurial的分布式軟件給遮蓋住了。微軟表示要取代它已經(jīng)好多年了。
原因是因為不支持如今的標準所導致的一系列缺陷使它一直不被看好。眾所周知它是微軟的悲劇系統(tǒng)，但不知何故它能堅持這么久，盡管它有那么多小故障，缺陷，并且不包含必需的功能（相對于今天的標準）。
第二誡.如果代碼沒放在源代碼管理軟件里，等于它不存在
每天重復讀這句話——“使用源代碼管理軟件是唯一的有效措施”。除非你在工作時使用項目的源代碼管理庫來控制代碼版本——否則代碼等于沒有存在過。
顯然你曾發(fā)覺在你的本地機器上運行良好的代碼在其他人那里運行的效果并不理想。是不是？他們不能獲取你的***版本，他們沒法去歸并代碼文件，你沒有正確地部署它（參考）而且如果你的SSD硬盤壞了的話你將永遠地失去你的勞動成果。
只要你保持這個心態(tài)——代碼只有提交后才是真的安全，才是其他良好編程習慣的保障。你可以把你的任務劃分成許多很小的單元以便你逐一提交。你需要頻繁地這么做。你就不必擔心你的硬件會不會出棘手問題。
不過更重要的意義是（至少對于你的團隊領導來說），通過源代碼管理軟件可以看到你做了什么。使用圖表并列出項目清單是個好方法，不過怎么知道他們實際上在做些什么？而使用源代碼管理軟件進行工作就能看得一清二楚了。
第三誡.要早提交，常提交，并且不要覺得麻煩
關于前面那點，避免“幻影代碼”（就是只能在你的機器上看到的代碼）的唯一方法是經(jīng)常提交你的任務并且不要覺得麻煩。它可以解決你的問題，不過這樣做也會對你的工作產(chǎn)生其他的影響：
1.每個提交的修訂都會為你提供一個還原點。如果你完全把代碼搞砸了（沒騙你，我們都這么做過），你是希望恢復到一個小時前的工作還是一周前的工作？
2.歸并文件時會出現(xiàn)的危險會隨著時間不斷增加。歸并文件一直很麻煩。如果你不是每天都保持提交代碼，某一天你會突然發(fā)現(xiàn)你和其他人的更改內(nèi)容會有50多個沖突。你不會為此感到高興的。
3.它促使你把任務分離成分散的單元。通常人們都是快完成的時候才提交的，因為他們想把代碼做成一個完整的邏輯單元模塊。不過龐大的任務不可避免地要分離出較小的分散功能，而頻繁地提交它們會使 你更了解它們，你可以一個個地構建并提交。
如果你做到這些，你的提交歷史不可避免地開始類似于一種半規(guī)律的樣式，里面每個工作日都是在提交任務。當然不總是這樣，也有停下來重構或測試，或者其他合理的活動也會中斷標準的開發(fā)周期。
然而，當我在看一個獨立的——尤其是完整的項目時，每當發(fā)現(xiàn)我們在一個標準的開發(fā)周期里，有一天或幾天什么都沒有做，我便會非常擔憂。我之所以擔憂是因為這意味著什么地方出問題了。一般不是有人正在想方設法要把問題搞定的話，就是因為卡在某個問題上而導致項目完全沒有進度。無論到底是什么情況，源代碼管理軟件都會告訴你出現(xiàn)問題了。
第四誡.提交前要檢查你更改了什么
往源代碼管理軟件里提交代碼的步驟其實非常簡單。（你恐怕會困惑上一條為什么說的那么麻煩。）一般只要發(fā)現(xiàn)文件內(nèi)容有變更時都會不顧后果地把文件傳上去。像這樣——“我的項目根目錄下有文件內(nèi)容變更了，我要快點提交上去！”
如此會發(fā)生一件（或兩件）事情：首先，程序員會沒有意識地把目錄下的垃圾代碼文件也上傳上去。一些人看到類似下面的窗口時，就會點擊“選擇全部”然后提交——這樣源倉庫里就會被本不應該存在的未調(diào)試的文件和其他垃圾文件給弄亂。
或者是，程序員實際上并沒有檢查他們更改過什么就把文件上傳了。當你在工作中處理配置文件或項目定義文件時很容易就不經(jīng)意把那些不想提交的文件給上傳了，而且那些文件很可能就被別的程序員用到了。你真的會記住你在配置文件里的所有更改嗎？
解決方法很簡單：你必須在提交前立刻檢查你改過什么地方。做起來其實比聽起來還要容易。使用許多系統(tǒng)已經(jīng)提供的“忽略”特性可以大幅度地減輕“不經(jīng)意上傳文件”的危險。你可以忽略Thumbs.db文件因為你壓根不想上傳它。你在每次修訂后可能還有其他文件不想上傳——那么就忽略掉它們吧！
至于文件里的更改，你通常可以使用某個流行的文本比較工具來觀察差異。為什么我又要上傳一次Web.config文件呢？
噢，我想起來了，我想把嘗試密碼失敗的***次數(shù)從5次減少到3次。啊，我差點沒注意把一個虛擬的登錄頁面給上傳上去了。這種在提交前做檢查的練習可以讓你更容易理解下一節(jié)的內(nèi)容。
第五誡.寫提交信息時一定要認真
這是一個古老的諺語（出處不詳），大意是說“寫每一條提交信息時就好象等下會讀到它的人是一個斧頭殺人狂，而且他還知道你住在哪里”。如果我是那個殺人狂并在研究你的代碼想追蹤bug的話，看到的提交信息全部都是“代碼更新了”，小心，我會來砍你的！
我的解決辦法就是解釋清楚為什么要提交新的代碼。每次你對代碼進行更改都是有原因的?？赡苁裁吹胤綍罎??？赡芸蛻舨幌矚g現(xiàn)在的主題顏色?？赡苣銉H僅要調(diào)整一下構建配置。無論是什么，這都是有原因的而且你要把原因用文字保留下來。
為什么？這樣做的原因有很多，而且在不同環(huán)境下各不相同。舉個例子，使用“歸屬”特性或其他類似的功能顯示出誰改了代碼那些地方。如果我不記得18個月之前我對項目的Web.config文件改過什么地方或者我為什么要改動應用程序的設置，是因為我沒有在當時留下一個適當?shù)奶峤恍畔?，而現(xiàn)在會非常簡單：
這是一個可以隨時觀察代碼更改的軟件的一種。無論我像下面那樣想了解一個文件的完整更改歷史，還是只想知道團隊昨天做了什么，留下一個描述性的相關記錄意味著只要不經(jīng)意一瞥就能知道是什么情況了。
***強調(diào)一下，當調(diào)試遇到錯誤時提交信息的重要性是無法估計的。舉個例子，在你的集成環(huán)境里的***更新的地方可以找到出錯的原因。我的例子是非常顯而易見的，不過把信息表示出來可以把很多棘手的問題變得極好解決。
把這條牢記于心，這里列出一些提交信息的反面教材：
1.可惡
2.能跑了
3.解決了一些混帳問題
4.解決了
5.改進了一點bug
6.上傳了
7.排字錯誤
8.修訂1024
好的，我從Stack Overflow網(wǎng)站的哪些是你寫過的最差勁的提交信息（譯者注：帖子已經(jīng)被刪除了，原因難道是出現(xiàn)了臟話？）帖子里選取了以上內(nèi)容，不過它們和我以前看過的提交信息并不相同。它們沒有告訴你有關代碼更改的任何有效信息；它們都是垃圾信息。
關于提交信息***要注意的是；同一個程序員之后提交信息絕不能和前面的完全相同。原因很好理解：你向源代碼管理軟件提交文件是因為對于上一個版本的代碼有東西改變了。你現(xiàn)在的代碼和之前的已經(jīng)不一樣了，如果你的提交信息是完整準確的，理論上就不能和前面的相同。如果是相同的（可能有時真的會這樣），日志就會難以閱讀，因為沒有辦法區(qū)分兩條提交有什么區(qū)別。
#p#
第六誡.你必須自己提交你的更改內(nèi)容——不能委托他人
聽起來很奇怪，但它的確會發(fā)生，我看過不止一次，最近的是上周。情況是這樣的，源代碼庫被視為極高的地位。因為很多原因，團隊會去追求***代碼的潔凈和單一。為了保持這種神圣的狀態(tài)，代碼只能由某個領頭的程序員來提交，他在提交前會小心地整合，審查并（大概會）調(diào)整改善代碼。
即使站在很遠也能很容易評價這個方案。不太頻繁的提交（可能一周幾次），只有一個脫離團隊其他程序員的人來提交，而且不可避免地在這段漫長的無提交時期里會有人的工作會導致項目混亂。非常非常不好。
這樣做會有兩個錯誤：首先，源代碼管理軟件并不意味著它里面代碼是神圣不可侵犯的；至少在整個開發(fā)周期里是這樣的。它應該是團隊頻繁整合文件，在出錯時還原到正常并且共同解決問題的地方。不是自始至終都要這樣做，只有在應用程序周期的發(fā)布時期為了達到某種狀態(tài)時才做的。
另一個問題——并且真的是極為關鍵的——站在程序員的視角，這樣等于你壓根沒有在用源代碼管理軟件！它等于沒有同伴之間的代碼整合，沒有還原，提交信息沒有負責人，什么都沒有！你們僅僅是在自己的象牙塔里各自寫各自的代碼然后等著未來順便某一天把它交給領導就完事了。
不要這樣做。千萬不要。
第七誡.一定要管理好數(shù)據(jù)庫的版本
這一點是我們都知道必須要做的，但是很多人覺得它麻煩。問題是很多（或者是大部分）應用程序沒了數(shù)據(jù)庫就不能運行。如果你沒有管理好數(shù)據(jù)庫，那你實際上做的就是一個不完整的完全無用的應用程序。
幾乎所有的版本控制系統(tǒng)的工作就是管理好文件系統(tǒng)內(nèi)的文件。它只是對像HTML頁面，圖片，CSS，項目配置文件和其他在文件系統(tǒng)的獨立單元這類典型應用作用較大。問題是它確實沒法在與程序有關聯(lián)的數(shù)據(jù)庫上起到作用。你總不能替換掉龐大的數(shù)據(jù)庫，把所有舊數(shù)據(jù)文件和包含一大堆對象和數(shù)據(jù)日志文件統(tǒng)統(tǒng)換掉。這樣會讓版本控制系統(tǒng)完全亂成一堆。
Red Gate公司開發(fā)的智能的SQL Source Control使這個情況得到了合理解決。我在去年寫的Rocking your SQL Source Control world with Red Gate這篇帖子里詳細說明了這款軟件，所以我現(xiàn)在就不多說了；總之就是數(shù)據(jù)庫管理現(xiàn)在會非常容易了！
老實說，如果你沒有管理好你的數(shù)據(jù)庫版本，你的開發(fā)會伴隨著很大的問題。在更改數(shù)據(jù)庫的時候沒有源代碼的管理，沒有還原點，并且很難和團隊密切合作。使用數(shù)據(jù)庫版本控制系統(tǒng)可以使開發(fā)更輕松。
第八誡.編譯生成的文件不要放進源代碼管理軟件里
簡單地說：在編譯運行項目時自動生成的結果文件不要放進源代碼管理軟件里。對于.Net開發(fā)的程序員，主要是"bin"和"obj"文件夾里通常會出現(xiàn)的.dll和.pdb文件。
為什么？因為如果你這樣做，你的同事會恨你的。這意味著每當他們從版本控制系統(tǒng)里取下***文件時會讓你的編譯文件覆蓋掉他們的。這是一個雙重噩夢（你絕不能這樣做），在他們下一次編譯時就會出問題。而且只要他們重新編譯后再把編譯文件重新上傳上去，同樣的問題會以相反的方向再發(fā)生一次，不過這次你是受害者。你肯定不想這樣的。
當然另一個問題就是這樣做很浪費。這會浪費源代碼管理服務器的硬盤空間，會浪費帶寬并會通過網(wǎng)絡發(fā)送時一直潛伏著，而且這樣做造成的不可避免的沖突會極度浪費你的時間。
所以我們繼續(xù)使用之前提到的“忽略”方案。只要把像"bin"和"obj"這樣的路徑直接忽略掉，一切就真的很輕松了。只要按照這種方法做一次，所有人都會感到開心的。
其實我在寫pre-commit hooks時就說到了在版本控制的服務器上不能提交此類文件。當然如果有值得這么做的原因的話，只有這種情況下你可以上傳。不過我傾向于不要這么做以免將來會導致某個人在更新時發(fā)生沖突。
第九誡.不要上傳你自己的用戶設置
老實說，我認為很多人沒有注意到他們把自己的私人設置文件上傳到源代碼管理軟件里了。這樣會出現(xiàn)的問題是：許多工具會產(chǎn)生只管理你自己本地配置的文件。它們只對你有用而且通常和其他人的私人設置文件相異。如果你把它們上傳到源代碼管理軟件里，很快你就會覆蓋掉其他人的私人設置文件。這樣并不好。
這是一個典型的.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" />
在這個例子里，僅僅是在用戶文件里記錄了我啟動了解決方案分析功能。這只是針對我，我喜歡這個功能，其他人則不一定。通常因為他們用的是老化的便宜的機子，我有點跑題了。關鍵是我的設置會強制讓其他人也執(zhí)行。我這么做不代表其他人也要這么做。
旁注：VSS不***的地方主要在于ignoring .ReSharper.user files is a bit of a problem?？梢钥纯催@篇帖子。
這個原理同樣也適用于.suo文件。不過這里看不到里面的內(nèi)容（它不是XML格式，而是二進制），這個文件記錄了解決方案瀏覽器的狀態(tài)，發(fā)布設置和其他一些你不讓強制用在其他人電腦的東西。
所以我們要再次使用忽略方案來處理。前提你現(xiàn)在用的不是VSS。
第十誡.附屬文件也要集成在一起
這是十誡中的***一條也是最最重要的一條。當應用程序需要外部的附屬文件存在才可以正常運行的話，把那些文件也都放進源代碼管理軟件里！人們傾向于犯的錯誤是，在他們擁有自己設置文件和本地附屬文件的環(huán)境里一切都表現(xiàn)得很好就把東西都上傳了，之后覺得沒問題了就不管了。但是其他人不能從源代碼庫里找到同樣的附屬文件的話，所有東西都會悲劇性地報錯。
我想到這點是因為今天從源代碼庫里拖出某個舊項目并運行它時出現(xiàn)了這樣的畫面：
我以為NUnit一直在機器上，但這次沒有。幸運的是使用NuGet可以快速解決問題，但是沒有附屬文件的話，不是每次都可以用同樣的方式就能輕松解決的。有些情況下，它們并不是公開的，你很難全部都獲取到。
我從源代碼管理軟件里取出的項目運行時之所以會報錯是因為我發(fā)現(xiàn)"C:\Program Files..."路徑下丟失了附屬的文件。我花了不少時間用來聯(lián)系***更改過它的那個人（很明顯他在世界上另一個很遠的地方），獲取了那個文件，把它放進"Libraries"文件夾下并把它上傳到了版本控制系統(tǒng)里，這樣下一個提取文件的人就不需要再這么麻煩了。
當然另一個重要的原因是，如果你在任何一種集成環(huán)境里工作時，你的構建服務器不一定安裝了那些庫。你必須有那些文件才能運行。Doug Rathbone最近寫了一篇很好的關于這點的文章Third party tools live in your source control(源代碼管理軟件里的第三方工具)。并不是非要那樣做（我們也善意地評價了效果），不過它確實是一個很方便的建議。
因此推薦每個人***天就把程序運行所需要的東西全都放進版本控制系統(tǒng)里。
總結
沒有哪一條是很難理解的。老實說，它們都很基礎：盡快并頻繁地提交，確認你提交的東西改了什么，還有東西一定要放進版本控制系統(tǒng)里，解釋清楚你的提交信息和確保是你自己提交的，不要忘記數(shù)據(jù)庫和不要忘記附屬文件。還有就是不要使用VSS:)
英文原文：The 10 commandments of good source control management
原文鏈接：http://www.ituring.com.cn/article/1322
【編輯推薦】
