日度归档：2018年6月9日

svn分支管理的使用与经验

最近项目用上了svn分支管理，因为项目太过庞杂，版本迭代也过于频繁，致使多个版本的代码交杂在一起，难以维护，无法保证其中某个版本的稳定性。当然，我们也用过很土的办法，代码复制一份出来，但是，这个副本也需要加上新开发的功能。

所以，我们决定使用svn分支管理。当然，这有代价，svn版本管理对二进制文件不友好，可能文件分支合并时二进制文件会难以处理。（这里说的二进制文件，泛指所有非文本文件，比如说美术资源，策划文档）

svn分支简述

使用分支最主要的目的是，多个分支可以并行，相互不干扰，而且任何时候都可以合并。其次，容易保证主干的稳定性。

没有分支的时候，你的svn可能是这样的：

就一份代码存在主干（trunk），当然也不会有主干这个说法。开发完1.0，继续开发2.0，版本一个一个迭代。

有了分支后，你的svn可能就是这样的了：

主干用来存放稳定的代码，每个版本都会开一个分支，等版本完成后再合并到主干。版本一个一个迭代，但可以并行开发。

svn分支管理

接下来，简单讲解下 如何使用svn做分支管理。

第一步，建立主干分支目录结构

第二步，创建分支

在主干目录 trunk 右键，在svn菜单选择 Branch/tag…

步骤①是分支地址，这里直接以 /branches/1

步骤②是取trunk版本，HEAD revision表示最新版本，其他可通过 show log选择

执行 OK 后，到 branches 目录 svn update 就可以看到最新的分支了。

第三步，合并分支到主干

分支就是开发目录了，现在分支提交一个文件做测试。

然后，合并这个文件分支到主干。

现在到主干目录，右键svn菜单选 Merge…

这个是将分支或主干的修改合并到当前工作目录，继续如下。

接下来点完成，如果没冲突的话，分支文件就合到主干了。

但这里还要一个操作，就是在主干提交分支合过来的文件。

题外话，之所以要有这一步，除了对分支内容进一步修改，还可以同时合并多个分支。选择权交给用户。

另外，主干内容合到分支，也是使用 Merge 命令。

svn分支应用

根据项目的不同，实际上的分支架构也会不同。以我们项目为例，我们是做游戏的，项目过于庞杂，版本迭代非常频繁。在版本1.1还没完成时，我们可能就要开发2.0版本，这样，版本1.1和版本2.0就要并行开发。而且，我们对稳定性有非常高的要求。

为此，我们设计了这样的svn架构。

测试分支

为了保证主干稳定，我们加了测试分支（如 rel_1.1的测试分支为 rel1.1_test ）。测试分支1.1是在分支1.1开发结束后开的，等待测试修复bug完成后，就会把测试分支1.1合入主干及分支1.1。合并完成后，这个测试分支将会关闭。

多分支并行

因为项目需求较多，版本迭代繁杂，所以在版本1.1还没结束时，就开了版本2.0的分支。当分支2.0需要测试合并到主干时，就会从主干合并最新的文件到2.0测试分支，测试通过后，再合并到主干。

分支合并的时机

对我们而言，不同分支的最大区别是功能上线的时间点。我们根据上线周期划分功能，拆分到不同分支。因为开发需求多，迭代过于频繁，所以靠后的分支对比之前的分支通常只是多了某些新功能。这样，分支的出现，避免了未开发完成的功能影响了已开发完的功能，导致当前版本的不稳定。所以，合并分支的时机就是这个分支的功能要不要上线。

这样，主干永远是稳定的，也只有经过测试的内容，才会合入主干。同时，多个版本也可以并行。

大型分布式团队的代码版本管理

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

  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等这类集中式版本管理工具还是更为适合。但是不管团队最终选用什么代码版本管理工具，只要适合自己的团队的开发流程和工作方式，并且代码管理顺畅就可以了。