原始碼管理的十條戒律

　　原始碼管理是我們工作中很重的一部分，是很多開發組的生命。但是我們往往在這方面犯錯，不理解很多基本的，核心的版本控制的概念。

　　我在這裡列出了十條建議，可以說是戒律。雖然我會用 Subversion 和 .NET 來做示例，但這些戒律和你用的程式語言還有原始碼管理工具無關。

　　1. 徹底拋棄 VSS！

　　VSS 已死，就讓它離去吧。它曾經很有用，但是現在其他 VCS（Version Control System）已經遠遠超越了它。微軟也決定從明年開始不再支援 VSS了。

　　老實說，在1995年，VSS是一個偉大的工具，但是它的光環早已被它的晚輩，Subversion，Git 和 Mercurial 奪去。

　　2. 沒有進入版本庫，它就不存在

　　你應該每天把這條念一遍 - “工作進展的唯一標準就是程式碼進了版本庫”。在程式碼進入版本庫之前，它相當於不存在。

　　我承認你的程式碼藏在你機器的某個角落，但是對於其他人來講，這有何意義？他們不能拿到你的最新版本，他們不能和你的版本合併，你也不能部署你的程式碼，一旦你的硬碟壞了，一切將煙消雲散。

　　如果你堅持的執行這一條的話，你會發現其他的好習慣會隨之而來。你會自覺的把任務分成小塊所以你可以經常提交程式碼。你會更加頻繁的更新，整合程式碼。最重要的是，經常提交程式碼說明了你正在做東西。

　　3. 儘早提交，儘快提交，經常提交

　　緊接上面一點，防止“幽靈程式碼”（只在你本地機器上能看到的程式碼）的唯一的方式就是把程式碼儘快的提交到版本庫。這麼做還有以下好處：

• 每次提交都會生成一個新的版本，給你回滾的機會。假如你把程式碼搞亂了，你是希望回滾到一小時前還是一個星期前？
• 間隔的時間越長，程式碼合併越困難。合併程式碼從來不是一件好玩的事情。當你好幾天都不提交程式碼，你會突然發現，你已經累計了50個衝突要解決，你大概會瘋掉。

　　當你堅持經常提交程式碼的習慣以後，你會發現你的工作、程式碼提交會呈現出一定的規律。這個規律可以用來指導你的開發工作。當你發現你的團隊好幾天都沒有程式碼提交的時候，你就會意識到 “something is wrong”。

　　4. 在提交前檢查你的更改

　　提交程式碼到版本庫看起來太簡單了。反正在專案的根目錄往下有東西更改了，提交吧！這樣會導致你提交了一堆垃圾。很多人看到下面的對話方塊的時候，往往是選擇所有，然後搞定！於是你的程式碼庫就被汙染了，例如debug資料夾之類的。

　　還有一些情況是人們提交程式碼前不檢查自己到底更改了什麼。例如一個專案配置檔案，你會記得你改了什麼嗎？也許這次修改就不應該提交呢？如下圖所示，這個Web.config檔案為什麼被修改了？你可以通過SVN工具對比來檢視更改。對於一些可能被更改但是不需要進入版本庫的檔案，例如 Thumbs.db，你可以用 SVN 的“ignore”功能來排除它。

　　5. 認真填寫“commit messages”

　　填寫 commit message（提交註釋）是有一點枯燥，但是想象一下別人看你的提交註釋的時候是拿著一把斧子，你把他逼瘋了他就來砍你！所以不要寫“更新了一段程式碼”這種提交註釋，你會把別人逼瘋掉。

　　“commit message”的目的解釋你提交程式碼到底修改了什麼。你也許不記得你一年前提交的一段程式碼是為什麼，但是 SVN 的註釋會讓你想起來。

　　所以，請不要寫以下這些註釋：

• 修復了一個bug
• 有一個拼寫錯誤
• 更新1024
• 這就是一坨屎
• 提交了

　　你還有見過比這個更爛的註釋嗎？還有，任何一個人的註釋應該是不一樣的，而且從邏輯上來講永遠不可能一樣，因為你每次提交程式碼的基礎一定是不一樣的，所以你做的事情不可能一樣。

　　6. 你必須自己提交程式碼，而不是讓別人代勞

　　這個聽起來有些奇怪。但這種事情確實存在，而且我還遇到過不止一次。有一些團隊為了保證程式碼庫的乾淨，讓一個人專門負責稽核和提交程式碼。這並不是一個好習慣。

　　首先，原始碼管理並不是為了保持程式碼的純淨，起碼在開發過程中不是這樣。它的目的是讓團隊更頻繁的整合各自的工作，當有問題的時候可以回退。在這個過程中，並不需要每一步都很完美。只有在版本釋出的時候，我們才需要，或者嘗試去達到“乾淨的程式碼”。

　　還有，從開發者的角度來看，這麼做等於沒有原始碼管理。因為它意味著沒有程式碼整合，沒有回退，沒有blame log，什麼都沒有。你只是坐在那裡寫程式碼，然後在你也無法確定的時間把程式碼交給你的老闆。

　　7. 資料庫的版本控制是必須的

　　這是有很多人想做，但是覺得很困難而做不到的一點。這裡的問題是，很多應用沒有資料庫根本無法執行。所以如果你不把資料庫加入版本控制的話，你的應用是不完整的。

　　大部分的版本控制系統只針對檔案系統工作，例如 HTML，CSS，圖片，配置檔案等等任何儲存在檔案系統中的東西。但是對於資料庫中的資料卻無能為力。

　　不過現在也有一些資料庫版本控制工具，例如 Red Gate 出品的 SQL Source Control。關於這個工具我曾經寫過很詳細的文章 Rocking your SQL Sourc Control world with Red Gate，我在這裡就不贅述了。總之，資料庫的版本控制也很容易了！

　　8. 編譯出來的檔案不應該加入版本控制

　　簡單的說，就是任何自動生成的東西都不應該放在版本庫裡面。以 .NET 為例，所有“bin”，“obj”資料夾下面的東西（.dll，.pdb等等）都不應該加入版本庫。

　　為什麼？因為如果這麼做了，你團隊的其他人會恨死你的。每次他們更新程式碼都會用你的編譯輸出來替代他們的編譯輸出，會導致他們本地的很多東西不能用。另外一個原因是，你完全沒有必要把這些編譯輸出放在版本控制裡面，它們只是在浪費伺服器的硬碟和頻寬。

　　9. 別人不在乎你的個人配置

　　很多時候，人們沒有意識到它們正在提交它們自己的個人配置到版本庫。開發工具往往會生成一些配置檔案，記錄你的檔案路徑，字型設定，快捷鍵設定等等，這些東西只對你有用。以 .NET 專案為例：

　　10. 依賴項也需要新增到版本庫

　　雖然這是最後一條，但也是很重要的。如果你的程式碼需要依賴第三方的類庫或者檔案，你需要把這些檔案也新增到版本庫。你不能認為程式在你的機器可以跑，就在別人的機器上也能跑。你團隊的其他成員也許沒有這些依賴的檔案，他們更新了你的程式碼以後，會導致專案無法編譯或者程式無法執行。

　　我今天還遇到一個這樣的問題。我拉下了很久以前的一個專案，然後出現下面的編譯錯誤：

　　這個專案也是我開發的，以前的工作環境總是有 NUnit 的，但是現在沒有了，所以出現了這些錯誤。

　　總結

　　這十條的每一條都很簡單，老實說都是很基礎的東西：及時，儘早的提交程式碼，充分了解你提交的東西，並確認它們確實需要被提交到程式碼庫，解釋你的提交，自己提交自己的程式碼，不要忘記資料庫版本控制，不要忘記依賴項。但請你忘記 VSS ：）

　　原文連結：10-commandments-good-source