源代碼管理的十條戒律
源代碼管理是我們工作中很重的一部分，是很多開發(fā)組的生命。但是我們往往在這方面犯錯(cuò)，不理解很多基本的，核心的版本控制的概念。
我在這里列出了十條建議，可以說是戒律。雖然我會(huì)用 Subversion 和 .NET 來做示例，但這些戒律和你用的編程語言還有源碼管理工具無關(guān)。
1. 徹底拋棄 VSS!
VSS 已死，就讓它離去吧。它曾經(jīng)很有用，但是現(xiàn)在其他 VCS(Version Control System)已經(jīng)遠(yuǎn)遠(yuǎn)超越了它。微軟也決定從明年開始不再支持 VSS了。
老實(shí)說，在1995年，VSS是一個(gè)偉大的工具，但是它的光環(huán)早已被它的晚輩，Subversion，Git 和 Mercurial 奪去。
2. 沒有進(jìn)入版本庫，它就不存在
你應(yīng)該每天把這條念一遍 - “工作進(jìn)展的唯一標(biāo)準(zhǔn)就是代碼進(jìn)了版本庫”。在代碼進(jìn)入版本庫之前，它相當(dāng)于不存在。
我承認(rèn)你的代碼藏在你機(jī)器的某個(gè)角落，但是對(duì)于其他人來講，這有何意義?他們不能拿到你的最新版本，他們不能和你的版本合并，你也不能部署你的代碼，一旦你的硬盤壞了，一切將煙消云散。
如果你堅(jiān)持的執(zhí)行這一條的話，你會(huì)發(fā)現(xiàn)其他的好習(xí)慣會(huì)隨之而來。你會(huì)自覺的把任務(wù)分成小塊所以你可以經(jīng)常提交代碼。你會(huì)更加頻繁的更新，集成代碼。最重要的是，經(jīng)常提交代碼說明了你正在做東西。
3. 盡早提交，盡快提交，經(jīng)常提交
緊接上面一點(diǎn)，防止“幽靈代碼”(只在你本地機(jī)器上能看到的代碼)的唯一的方式就是把代碼盡快的提交到版本庫。這么做還有以下好處：
每次提交都會(huì)生成一個(gè)新的版本，給你回滾的機(jī)會(huì)。假如你把代碼搞亂了，你是希望回滾到一小時(shí)前還是一個(gè)星期前?
間隔的時(shí)間越長，代碼合并越困難。合并代碼從來不是一件好玩的事情。當(dāng)你好幾天都不提交代碼，你會(huì)突然發(fā)現(xiàn)，你已經(jīng)累計(jì)了50個(gè)沖突要解決，你大概會(huì)瘋掉。
當(dāng)你堅(jiān)持經(jīng)常提交代碼的習(xí)慣以后，你會(huì)發(fā)現(xiàn)你的工作、代碼提交會(huì)呈現(xiàn)出一定的規(guī)律。這個(gè)規(guī)律可以用來指導(dǎo)你的開發(fā)工作。當(dāng)你發(fā)現(xiàn)你的團(tuán)隊(duì)好幾天都沒有代碼提交的時(shí)候，你就會(huì)意識(shí)到 “something is wrong”。
4. 在提交前檢查你的更改
提交代碼到版本庫看起來太簡單了。反正在項(xiàng)目的根目錄往下有東西更改了，提交吧!這樣會(huì)導(dǎo)致你提交了一堆垃圾。很多人看到下面的對(duì)話框的時(shí)候，往往是選擇所有，然后搞定!于是你的代碼庫就被污染了，例如debug文件夾之類的。
還有一些情況是人們提交代碼前不檢查自己到底更改了什么。例如一個(gè)項(xiàng)目配置文件，你會(huì)記得你改了什么嗎?也許這次修改就不應(yīng)該提交呢?如下圖所示，這個(gè)Web.config文件為什么被修改了?你可以通過SVN工具對(duì)比來查看更改。對(duì)于一些可能被更改但是不需要進(jìn)入版本庫的文件，例如 Thumbs.db，你可以用 SVN 的“ignore”功能來排除它。
5. 認(rèn)真填寫“commit messages”
填寫 commit message(提交注釋)是有一點(diǎn)枯燥，但是想象一下別人看你的提交注釋的時(shí)候是拿著一把斧子，你把他逼瘋了他就來砍你!所以不要寫“更新了一段代碼”這種提交注釋，你會(huì)把別人逼瘋掉。
“commit message”的目的解釋你提交代碼到底修改了什么。你也許不記得你一年前提交的一段代碼是為什么，但是 SVN 的注釋會(huì)讓你想起來。
所以，請(qǐng)不要寫以下這些注釋：
◆ 修復(fù)了一個(gè)bug
◆ 有一個(gè)拼寫錯(cuò)誤
◆ 更新1024
◆ 這就是一坨屎
◆ 提交了
你還有見過比這個(gè)更爛的注釋嗎?還有，任何一個(gè)人的注釋應(yīng)該是不一樣的，而且從邏輯上來講永遠(yuǎn)不可能一樣，因?yàn)槟忝看翁峤淮a的基礎(chǔ)一定是不一樣的，所以你做的事情不可能一樣。
6. 你必須自己提交代碼，而不是讓別人代勞
這個(gè)聽起來有些奇怪。但這種事情確實(shí)存在，而且我還遇到過不止一次。有一些團(tuán)隊(duì)為了保證代碼庫的干凈，讓一個(gè)人專門負(fù)責(zé)審核和提交代碼。這并不是一個(gè)好習(xí)慣。
首先，源代碼管理并不是為了保持代碼的純凈，起碼在開發(fā)過程中不是這樣。它的目的是讓團(tuán)隊(duì)更頻繁的集成各自的工作，當(dāng)有問題的時(shí)候可以回退。在這個(gè)過程中，并不需要每一步都很完美。只有在版本發(fā)布的時(shí)候，我們才需要，或者嘗試去達(dá)到“干凈的代碼”。
還有，從開發(fā)者的角度來看，這么做等于沒有源代碼管理。因?yàn)樗馕吨鴽]有代碼集成，沒有回退，沒有blame log，什么都沒有。你只是坐在那里寫代碼，然后在你也無法確定的時(shí)間把代碼交給你的老板。
7. 數(shù)據(jù)庫的版本控制是必須的
這是有很多人想做，但是覺得很困難而做不到的一點(diǎn)。這里的問題是，很多應(yīng)用沒有數(shù)據(jù)庫根本無法運(yùn)行。所以如果你不把數(shù)據(jù)庫加入版本控制的話，你的應(yīng)用是不完整的。
大部分的版本控制系統(tǒng)只針對(duì)文件系統(tǒng)工作，例如 HTML，CSS，圖片，配置文件等等任何保存在文件系統(tǒng)中的東西。但是對(duì)于數(shù)據(jù)庫中的數(shù)據(jù)卻無能為力。
不過現(xiàn)在也有一些數(shù)據(jù)庫版本控制工具，例如 Red Gate 出品的 SQL Source Control。關(guān)于這個(gè)工具我曾經(jīng)寫過很詳細(xì)的文章 Rocking your SQL Sourc Control world with Red Gate，我在這里就不贅述了?？傊?，數(shù)據(jù)庫的版本控制也很容易了!
8. 編譯出來的文件不應(yīng)該加入版本控制
簡單的說，就是任何自動(dòng)生成的東西都不應(yīng)該放在版本庫里面。以 .NET 為例，所有“bin”，“obj”文件夾下面的東西(.dll，.pdb等等)都不應(yīng)該加入版本庫。
為什么?因?yàn)槿绻@么做了，你團(tuán)隊(duì)的其他人會(huì)恨死你的。每次他們更新代碼都會(huì)用你的編譯輸出來替代他們的編譯輸出，會(huì)導(dǎo)致他們本地的很多東西不能用。另外一個(gè)原因是，你完全沒有必要把這些編譯輸出放在版本控制里面，它們只是在浪費(fèi)服務(wù)器的硬盤和帶寬。
9. 別人不在乎你的個(gè)人配置
很多時(shí)候，人們沒有意識(shí)到它們正在提交它們自己的個(gè)人配置到版本庫。開發(fā)工具往往會(huì)生成一些配置文件，記錄你的文件路徑，字體設(shè)置，快捷鍵設(shè)置等等，這些東西只對(duì)你有用。以 .NET 項(xiàng)目為例：
10. 依賴項(xiàng)也需要添加到版本庫
雖然這是最后一條，但也是很重要的。如果你的代碼需要依賴第三方的類庫或者文件，你需要把這些文件也添加到版本庫。你不能認(rèn)為程序在你的機(jī)器可以跑，就在別人的機(jī)器上也能跑。你團(tuán)隊(duì)的其他成員也許沒有這些依賴的文件，他們更新了你的代碼以后，會(huì)導(dǎo)致項(xiàng)目無法編譯或者程序無法運(yùn)行。
我今天還遇到一個(gè)這樣的問題。我拉下了很久以前的一個(gè)項(xiàng)目，然后出現(xiàn)下面的編譯錯(cuò)誤：
這個(gè)項(xiàng)目也是我開發(fā)的，以前的工作環(huán)境總是有 NUnit 的，但是現(xiàn)在沒有了，所以出現(xiàn)了這些錯(cuò)誤。
總結(jié)
這十條的每一條都很簡單，老實(shí)說都是很基礎(chǔ)的東西：及時(shí)，盡早的提交代碼，充分了解你提交的東西，并確認(rèn)它們確實(shí)需要被提交到代碼庫，解釋你的提交，自己提交自己的代碼，不要忘記數(shù)據(jù)庫版本控制，不要忘記依賴項(xiàng)。但請(qǐng)你忘記 VSS ：)
原文：http://www.oschina.net/news/26427/10-commandments-good-source-control
【編輯推薦】
