SCM与源代码管理

源代码管理并不是一个老话题，但是实际实施过程中存在许多不正确的方式和理解。

1.管理什么？
对代码的访问设定权限，通过不同授权让成员使用；为代码提供一个集中存储的空间，让成员间能够保持同样的代码环境。这是绝大多数实施的唯一方式和理由。这种方式忽视了一个重要的概念“传承”，直白点说就是管理应该能够让“加入的”成员能够了解“离开的”成员的“思路与过程”，以保证开发团队的稳定性，减少技术与成员之间的捆绑。“传承”需要靠详细的“历史信息”来体现，这其中要求提交时的信息必须“足够”，而管理就是这种方式的保障。

2.为什么管理？
不仅仅是“技术保密”，代码管理的目的是让“被管理的代码”有效的保证“产品的开发”。而这一切都是以“人”作为主体来实现的，管理的方式必须能够保证成员的流动不造成“技术断层”，不影响产品的拓展开发。“技术保密”事实上是一个“伪”命题，真正的保密性是不存在的，因为涉及的人员存在“流动”的必然；而“保密性”的价值在于“在一定的时间内”技术是先进的，只要保证在“这段时间内”核心人员不流动就可以了。

3.怎样选择SCM？
SCM自身是有一个演化的过程的，从“源代码存储”到“源代码管理”用了足够长时间的演变。我们必须理解的是“SCM不是源代码管理的充要条件，但是源代码管理的必要条件”。管理者由于使用SCM的历史不同有两个阵营“集中式”和“分布式”，但事实是原属于“集中式”SCM本身也在向“分布式”进行演化，比较典型的是SVN+SVK组合；历史的必然是“分布式”将是SCM唯一的方式。典型的区别是，修改完一些代码后进行提交，如果本地代码与远程代码之间有冲突：集中式”SCM的合并后自身的修改历史将不得不被压缩为；而“分布式”SCM能够让合并后自身的修改历史独立保存是。可见，“分布式”SCM能够保证“传承”所需要的全部历史信息。我个人推荐Git，简单、强大而跨平台。

4.怎样编写代码？
看似弱智的问题，但颇有玄机：SCM以怎样的方式在编码过程中使用？我的观点是，SCM在项目开始的阶段就进行使用，并作为唯一的代码备份方式。
1）我们在浏览“前人”的代码中会发现很大段“注释掉的代码”，这些代码对于前人来说是自身思路的一个备份，但对“后人”来说只仅仅是垃圾。SCM的使用能够让我们放心的“删除”废弃不用的代码，即便是以后用到也可以通过“浏览”SCM历史的方式获得。
2）有些成员喜欢在自己修改的代码前加入自己“姓名”的记号并加入很明显的分隔符，这些与“被注释掉的代码”一样也属于垃圾，个人信息只应该在SCM的历史中体现。
3）代码粒度也是非常重要的一个问题，如果一次提交包含了N多功能的修改，那么他的历史信息就太稀少了；最典型的应用就是每个功能都应该作为独立提交。