介绍这个话题，有两个原因：

1. 从开始工作到现在，我经历过没有代码版本管理、代码集中式管理，以及现在的分布式管理，我深刻体会到它在软件开发过程中的重要性；
2. 我在工作中遇到的很多客户都存在对于代码版本管理的各种问题、困惑和不同的需求。

所以我希望将我在这个方面的经验分享给更多人，希望能帮助更多的团队解决在代码版本控制方面的问题和疑惑。

（图片来自：http://t.cn/RSPnA5t）

一、代码版本管理系统的历史

代码版本管理系统大致可以分为三个时代：

第一代：本地式

这代主要的特点提供本地代码版本控制，比如SCCS(1972)、 PVCS(1985)等。

这代主要实现了基本的代码版本管理，但缺点是无法让多人同时对一个版本库进行修改。这个也和当时软件规模不够大有关，也没有这样的需求。

第二代：客户端-服务器式

这代主要的特点是提供集中式服务器端代码版本控制,比如 CVS(1986), ClearCase(1992), Visual SourceSafe(1994), Perforce(1995), Subversion(2000) 等。

这代主要是实现了中心服务器端的代码版本管理，特点是可以让多人同时对一个代码版本库进行同步和修改，但缺点也相当明显：

1. 在无法连接服务器的情况下，无法查看日志以及提交和比较代码版本（慢速网络和远程异地工作的程序员的痛），以及当服务或者网络出现问题的时候很多人员就会无法工作。
2. 不支持local branch，导致branch创建管理复杂，并且一旦创建就很难修改（快速迭代开发中的程序员的痛）
3. 由于只有一个中心端服务器，一旦发生灾难性问题，那么所有日志都会丢失，所以需要经常做备份（备份需要不小的成本）
4. 如果软件代码量过于庞大，一般会出现速度缓慢的情况，因为每次的日志查询、不同版本之间的代码比较和代码提交等操作都需要和服务器通信，造成服务器端的负载过大。

第三代：分布式

这代主要的特点是提供分布式代码版本控制,比如Git(2005), Mercurial(2005)等。

这代结合了第一代和第二代的优点并实现了分布式的代码版本管理。

这代的优点：分布式管理，在没有和服务器有连接的情况下仍然可以查看日志，提交代码，创建分支；支持local branch，可以快速方便的实现各种分支管理；支持分布式，从而可以实现分块管理，以及负载分流管理。

缺点是有一定的学习曲线，比如分布方式下的代码同步，local branch的理解与运用，分布式代码管理的理解与运用等。详细的比较可以参考：这里。

二、大型分布式团队

曾经有这样一个分布式团队，他们在多个城市都有小分队，并且正在开发一个大型项目，见下图

他们使用的代码版本管理工具是第二代代码管理工具SVN，管理方案如下：

但是他们在使用的过程中却遇到了下面这些问题与痛点。

由于是分布式团队，所以：

• 基于团队的代码模块分离困难

当服务器不可用时：

• 不能查看提交记录
• 不能比较文件
• 不能提交代码

创建代码分支时：

• 分支创建速度慢
• 多分支管理困难

在提交代码时：

• 希望有Code Review
• 希望有CI Review

因为代码庞大：

• 查看日志慢

备份代码库的时候：

• 需要停机备份
• 备份成本高

针对以上问题，可以使用新一代的分布式的代码版本管理系统来解决，见下图：

其中每一个团队都有自己独立的代码库，有一个中心库用于同步这些独立的代码库，并且每个库都由团队自己管理和维护。而且代码版本管理系统需要支持轻量分支，代码评审，离线提交，离线查看日志等功能。

但是由于当前没有一个单一的代码版本管理工具能同时满足以上所有需求，所以很多公司都基于它们开发集成管理系统，比如Gerrit，GitLab，GitHub，BitBucket等。其中的Gerrit由于其开源，免费，以及由Google开发和维护，并管理着Android，OpenStack等大型项目源代码的特点，成为了大型分布式团队优先选择的系统。

三、Gerrit

Gerrit是由Google开发的，用于管理Google Android项目源代码的一个系统。它是基于Java和Prolog等开发的，支持Git，权限管理，代码评审等综合的一个管理系统。它与GitLab和GitHub最大的不同是它隐藏了代码分库管理的细节，使得开发人员不需要进行fork这样的手工分库和同步操作就可以进行代码开发和提交，节省了开发人员的时间,见下图。

由于Android本身是一个开源项目，所以贡献者非常多，开发团队也遍布多个地方（存在时差），导致“如何保证代码质量”成为一个很大的问题。为此Google在Gerrit中加入了功能强大并且十分严格的代码评审系统。

首先当代码提交以后并不会直接merge到中心库里面，它会暂时存在一个临时库里面，同时生成一个代码评审记录，并向特定的评审人员发送请求评审的邮件。当评审者在评审代码之后，如果通过就需要在Gerrit系统里面对代码进行打分，如果通过了就可以将代码merge到中心库里面去，如果没有通过，那么这个代码提交就需要被返还给开发者进行修改。

与此同时它还可以自动触发一次包含本次代码提交的CI构建（前提需要手工预先配置），如果CI自动构建和测试通过，也可以自动在Gerrit系统里面进行打分，可以给最终进行merge的人员进行参考。示意流程见下图。

由于Android源代码由上百个独立的代码库组成，并且编译一个Android系统需要大部分代码库里面的代码，所以如何管理如此多的代码库也是一个难题，比如如何一次性同步需要编译一个需要支持特定设备的代码库组合。为此Google基于Python语言开发一个工具叫Repo ，这个工具可以自定义你需要的代码库的组合，并且一次性对这些代码库进行同步，比如pull和push，见下图。

四、SVN到Git的迁移

对于想从集中式代码管理系统迁移到分布式代码管理系统的团队来讲，如果团队规模小，那么问题一般都不大，但是对于大型分布式团队却是困难重重。最主要的两个困难：

1. 代码量太大，很难一次性将所有的代码和日志等在短时间内迁移成功。
2. 由于下属团队太多，很难同一时间让所有团队都切换至新的代码管理工具。

为了解决这些难题，一般都会首先选用1个团队来使用新的代码版本管理工具。如果这个团队转换成功，再将其作为标杆向其他团队推广，从而逐步的将所有团队切换到新的工具上去。

SVN到Git的迁移方案一般主要会使用两种工具：

1. 开源免费的git-svn；
2. 商业收费的Subgit。

其中使用Subgit的迁移方案如下图：

如果团队组资源充足，还可以使用Gerrit搭建一个独立的Git服务器，从而以分布式的方式进行代码迁移，如下图：

五、多产品线的管理

使用同一个中心代码库管理多产品线一直是大型项目的一个困难点，特别是使用SVN这样的工具更是难以管理，因为SVN这种工具的Branch本质上是一个目录拷贝，并且速度慢，而且代码回迁也需要手动进行。但是如果使用Git的特性来管理多产品线，比起SVN是事半功倍。具体方案见下图：

总结：

分布式代码版本管理系统并不一定适合所有团队，比如中小团队可能更关心的只是成本更低，简单易用，那么SVN等这类集中式版本管理工具还是更为适合。但是不管团队最终选用什么代码版本管理工具，只要适合自己的团队的开发流程和工作方式，并且代码管理顺畅就可以了。

Launchpad PPA Repositories是很有用的非ubuntu官方的第三方个人资源库，可以很方便地安装第三方软件。

apt-get install software-properties-common

一、什么是story point

Story point，翻译成中文即为故事点。
故事点是Scrum团队使用的一种随机度量方式，用来度量实现一个故事需要付出的工作量”，还可能是“故事点数的估算混合了对于开发特性所要付出的努力、开发复杂度、个中风险以及类似东西。
我们也可以理解为可以用story point来衡量一个issue的难度或工作量。

二、story point的预估

估计story point常用的两个标准如下，在这里我主要以Fibonacci为例讲解。

• Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 21,34, 55, 89
• Power of 2: 0, 1, 2, 4, 8, 16, 32, 64,128

story point虽然可以分为12个等级，但我们在现实中一般只采用0、1、2、3、5、8、13这七个等级。如果在预估中发现超过13的，我们一般把任务进行分割，分割为两部分，循环该步骤，直至所有point都小于等于13。

一开始我们选取之前预估为3的Issue来跟要预估的Issue进行比较，如果两个工作量差不多，设置该Issue的story point为3，如果工作量略少，则为2，更少的话则设置为1，如果该Issue不需要完成的则设置为0，该情况一般不会出现。
同理可得，如果工作量较大，相应的设置为5/8/13。