介绍

本地版本控制：

• 基本原理：本地保存所有变更的补丁集，通过这些补丁可以计算出每个版本实际的文件内容
• 缺点：RCS这种本地版本控制存在着致命的缺陷：仅可以在本地使用，无法进行团队协作，使用场景有限

集中式版本控制：

• 基本原理：
  1. 提供一个远程服务来保存文件所有用户的提交都保存到该服务器中
  2. 增量保存每次提交的Diff，如果提交的增量中和远端现存的文件存在冲突，需要提前解决
• 优点：
  1. 学习简单，更容易操作
  2. 支持二进制文件，对大文件更友好
• 缺点：
  1. 本地不存储版本管理的概念，所有提交都需要连上服务器后才能提交
  2. 分支上的支持不够好，大型项目团队合作较困难
  3. 用户本地不保存所有版本的代码，如果服务器端故障会导致历史版本的缺失

分布式版本控制：

• 基本原理：
  1. 每个库都有完整的提交历史，可以在本地进行代码提交
  2. 每次提交都有完整的文件快照，而不是记录增量
  3. 通过push等操作和远端代码的同步
• 优点：
  1. 分布式开发，每个库都是完整的提交历史，支持本地提交，强调个体
  2. 分支管理功能强大，方便团队合作，多人协作开发
  3. 校验和机制保证完整性，一般只添加数据，很少执行删除操作，不易导致代码丢失
• 缺点：
  1. 相对SVN学习更复杂，学习成本更高
  2. 对大文件支持不友好

基本使用

研发流程

集中式工作流

只依托master分支进行研发活动

Gerrit

工作方式：

1. 依托于Change ID的概念，每个提交生成一个新的代码评审
2. 提交上去的代码不会存储在真正的refs/heads/下的分支中，而是存在一个refs/for/的引用下
3. 通过refs/meta/config/下的文件存储代码的配置，包括权限，评审等配置，每个Change都需要完成Review后才能合入

优点：

• 提供强制的代码评审机制，保证代码的质量
• 提供更丰富的权限功能，可以针对分支做细粒度的权限管控
• 保证master的历史整洁性
• Aops多仓的支持情况更好

缺点：

• 开发人员多，容易产生冲突
• 多分支的支持较差，想要区分多个上新版本的代码时，容易出现问题
• 一般只有管理员才能创建仓库，比较难以形成代码复用

分支管理工作流

代码合并