作者：张克强 作者微博：张克强-敏捷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