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