作者：張克強??? 作者微博：張克強-敏捷307

建議之1:使用好的配置管理工具，也稱為版本控制工具（Version Control), 比如Git，SVN。 請徹底拋棄 VSS，如果是新采用配置管理工具，CVS已經不再是選項。 配置管理工具與版本控制工具可以理解為指的是相同工具。

建議之2：拋棄古老的配置管理三庫做法，常說的三庫是指開發庫（動態庫）、受控庫和產品庫（靜態庫）；做法是開發庫->受控庫->產品庫。 在當年沒有強大版本控制工具的“古代”，三庫做法是不得不的選擇，而在現代版本控制工具（比如CVS，SVN，Git等）的支持下，三庫做法變得落伍了。

建議之3：納入配置管理的文件的名稱里不要含有版本號。當前的配置管理工具都有強大的版本控制功能，而只要在文件名中加入版本號，那么相當于放棄工具的版本控制功能，而只是把配置管理工具當成了普通的存儲空間，就像共享目錄、FTP一樣。

建議之4：必須自己提交代碼，而不是讓別人代勞。有一些團隊為了保證代碼庫的干凈，讓一個人專門負責審核和提交代碼。這并不是一個好習慣。源代碼管理并不是為了保持代碼的純凈，起碼在開發過程中不是這樣。它的目的是讓團隊更頻繁的集成各自的工作，當有問題的時候可以回退。

建議之5： 沒有進入版本庫，它就不存在，“工作進展的唯一標準就是代碼進了版本庫”。如果堅持執行這一條的話，發現其他的好習慣會隨之而來。把任務分成小塊所以經常提交代碼，更加頻繁的更新，集成代碼。最重要的是，經常提交代碼說明了正在做東西。

建議之6：識別代碼配置項和非配置項。非配置項的例子有target目錄，.class文件，.clashpath,.project, .sonar, thumbs，debug文件夾等等，利用ignore功能把非配置項忽略掉。代碼配置項要完整，在別處能編譯得到相同結果，但是又不干擾別處的工作環境。

建議之7：每個團隊應當對代碼配置項和非配置項有所說明，不要假設每個團隊新人都是代碼配置管理達人，小心自以為是的新手加入一些自以為是的垃圾。雖然可以刪除，但發現再刪除，其本身就是成本。

建議之8：依賴項也需要添加到版本庫，或者維護好相應的庫，其中最重要的是構件庫。 同時也包括圖片，編譯腳本，數據庫腳本，自動化測試等等。

建議之9：整體環境在云計算條件下也是可以成為配置項，環境中最突出的元素是基礎數據。當需要多種不同的環境（比如干凈環境、仿真環境、某個時間點環境）進行調試、測試的時候，得到配置管理的環境在1分鐘之內部署出來，那是多么高效的事情。 測試人員愛死這個了!

建議之10：避免表面CMMI做法-只管理維護一個受控庫，展現給評估組和應付各類檢查，而實質上，項目團隊使用另外的庫開展日常工作，只在應付檢查時才把強制要求的交付物復制到受控庫。 這種做法滿足CMMI評估，但實質上沒有發揮配置管理的更多好處。古老的三庫方案恰恰就是這樣子的。

建議之11：了解最普通的多分支開發。多分支開發是最經典最常用的模式，無論是否采用，應當知道多分支是如何玩的：如何拉分支？什么情況下拉分支？如何合并到主干？如何再從主干更新到分支？如何合并到其它分支？什么情況下合并分支后不再維護分支？合并沖突如何解決？

建議之12：守護主干+先鋒分支，在主干上修復缺陷以及應急響應，而把新功能放到分支上開發，在分支上測試通過后合并到守護主干，再發新版。這種做法適用于承擔大量運維修改的情景。也許多數軟件產品屬于這種情景。

建議之13：主干開發。主干開發有兩種情況，情況1：還沒有掌握分支開發，只會主干開發；情況2：充分掌握了分支開發之后，主動選擇主干開發。顯然的建議是指情況2。主干開發風險高，效率也高，值得碼匠們好好研究，實現高質量并且高效的主干開發并不絕對的困難，收益是絕對劃算的。

建議之14：單分支開發。單分支開發其實與主干開發沒有本質差別，需要采取主干開發的所有方法，日常工作在分支上進行，主干用于應急響應，兩者需要頻繁的雙向同步。 這樣的模式是兼有守護主干和主干開發的好處，但顯然的復雜度提升了。

建議之15：所有的配置項一起得到基線管理。 主要包括源代碼、文檔和測試代碼，如果不在同一個庫中，那么需要專門的基線文件來說明同一基線的對應關系。這不能算建議了，這是配置管理的基本要求了，但往往被違反。

參考材料

程序員開發利器：源代碼管理的十條建議

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

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

總結

以上是生活随笔為你收集整理的源代码管理的新15条建议的全部內容，希望文章能夠幫你解決所遇到的問題。

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