晨光（Morning） 版本控制 软件开发 对于一个采用版本控制进行软件开发的多人开发团队而言，其一般的开发方式是：采用服务器/客户端的形式，在上面分别安装版本控制工具的服务器和客户端版本，软件放在服务器上为大家所共享，开发人员在客户端从服务器上将软件的相关部分下载到本地，进行修改，改动结果最终提交到服务器上。 版本控制的功能：跟踪记录整个软件的开发过程，包括软件本身和相关文档（所带来的结果是：可标识不同阶段的软件及相关文档，进行差别分析；对软件进行可撤消的修改；便于汇总不同人员所做的修改），辅助协调和管理软件开发团队。 我认为，对于软件的版本控制而言，其主要特点包括如下： 由于采用服务器/客户端方式，尽管开发人员可以在自己的本地留有备份，但最终唯一有效的只有服务器端的那个原始拷贝。一定程度可以解决一致性问题、冗余问题。[1] 工具将会自动记录每个更改细节，和不同时期的不同版本。一定程度可以解决冗余问题、事务性问题、并发性问题。[1] 对于不同开发人员，对软件的不同部分可以定义不同的访问权限。一定程度可以解决安全性问题。[1] 由于有工具辅助控制，可以减轻开发人员的负担，节省时间，同时降低人为错误。像软件整合这样的工作，其工作量可以相对减轻。[1] 我认为，对软件进行版本控制，衡量其效果的标准，归根结底有两点：效率和质量。如果版本控制最终使软件开发效率得到提高、使软件质量得到提升，那就是成功的，反之则是失败的。效率的提高比较容易理解，质量的提升则体现在：软件的一致性、冗余程度等。需要指出的是，单就版本控制工具本身并不能保证这两点。对工具不熟悉或错误的使用，以及开发人员的不良习惯等都将导致失败。有时可能反而降低效率。 我认为，广义的版本控制也应该包括和代码相关的其他内容，主要指文档。虽然文档的一致性问题并不像代码那么突出，多人同时修改一个文档的情况一般较为少见，但将文档只留一个服务器拷贝，会便于集中管理，减少冗余，加上工具的全程跟踪记录，可以随时查看不同时期文档的内容，相互比对。 在版本控制中，人的因素更为重要，规范的行为可以避免很多意想不到的后果，和错误使用工具所引起的问题。单纯依赖工具，并不能取得良好效果。没有版本控制的意识、对工具的使用不熟悉（一些功能不知道怎么用，一些功能使用错误）、人为的不良习惯，都可能导致错误。因此需要使用版本控制工具的开发人员具有自觉良好的意识和习惯，也需要一些相关的规范和制度的保证。 可以不必单独划定一人来担任这个角色，但如果没有这一角色的存在，任何人都可以任意操作服务器上已纳入版本控制的软件以及版本控制工具的配置信息（比如用户权限信息），或者说任何人都可以做管理员，则又会出现安全性问题。从某种程度上讲，这和没有版本控制下每台机器上都有若干软件版本的情况是等效的。 对于一个团队而言，向版本控制过渡，需要有一个逐步转变的过程。这包括：制订一系列合理的循序渐进的措施，使版本控制的意识逐步得到大家的认可，使人员逐渐养成良好习惯（习惯于这种开发方式）。这是一个持久的过程，需要坚持。 [1] 参见《没有使用版本控制的黑暗时代——版本控制心得（一）》一文 另：本文已在csdn上贴出，查看相关评论请到这里