英文原版 http://java.dzone.com/articles/10-commandments-good-source?

本文轉自中文翻譯改寫版 ?http://tech.it168.com/a2012/0307/1321/000001321198.shtml

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

　　我在這里列出了十條建議，可以說是戒律。雖然我會用 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 ：)

總結

以上是生活随笔為你收集整理的程序员开发利器：源代码管理的十条建议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。