引子：知乎问题？php
代码版本控制用SVN仍是Git好？ SVN和Git都有分支，如今须要对代码进行版本控制，都各有什么优缺点？二者都有用过，可是仅限于会使用，更多的利弊仍是不太了解。公司对目录权限访问控制要求严格，员工以前一直用的SVN。如今是打算都用git
-------------------------------------------------------------------------------------------------------程序员
介绍这个话题，有两个缘由：服务器
- 从开始工做到如今，我经历过没有代码版本管理、代码集中式管理，以及如今的分布式管理，我深入体会到它在软件开发过程当中的重要性；
- 我在工做中遇到的不少客户都存在对于代码版本管理的各类问题、困惑和不一样的需求。
因此我但愿将我在这个方面的经验分享给更多人，但愿能帮助更多的团队解决在代码版本控制方面的问题和疑惑。网络
（图片来自：http://t.cn/RSPnA5t）分布式
1、代码版本管理系统的历史
代码版本管理系统大体能够分为三个时代：svn
第一代：本地式工具
这代主要的特色提供本地代码版本控制，好比SCCS(1972)、 PVCS(1985)等。学习
这代主要实现了基本的代码版本管理，但缺点是没法让多人同时对一个版本库进行修改。这个也和当时软件规模不够大有关，也没有这样的需求。测试
第二代：客户端-服务器式
这代主要的特色是提供集中式服务器端代码版本控制,好比 CVS(1986), ClearCase(1992), Visual SourceSafe(1994), Perforce(1995), Subversion(2000) 等。
这代主要是实现了中心服务器端的代码版本管理，特色是可让多人同时对一个代码版本库进行同步和修改，但缺点也至关明显：
- 在没法链接服务器的状况下，没法查看日志以及提交和比较代码版本（慢速网络和远程异地工做的程序员的痛），以及当服务或者网络出现问题的时候不少人员就会没法工做。
- 不支持local branch，致使branch建立管理复杂，而且一旦建立就很难修改（快速迭代开发中的程序员的痛）
- 因为只有一个中心端服务器，一旦发生灾难性问题，那么全部日志都会丢失，因此须要常常作备份（备份须要不小的成本）
- 若是软件代码量过于庞大，通常会出现速度缓慢的状况，由于每次的日志查询、不一样版本之间的代码比较和代码提交等操做都须要和服务器通讯，形成服务器端的负载过大。
第三代：分布式
这代主要的特色是提供分布式代码版本控制,好比Git(2005), Mercurial(2005)等。
这代结合了第一代和第二代的优势并实现了分布式的代码版本管理。
这代的优势：分布式管理，在没有和服务器有链接的状况下仍然能够查看日志，提交代码，建立分支；支持local branch，能够快速方便的实现各类分支管理；支持分布式，从而能够实现分块管理，以及负载分流管理。
缺点是有必定的学习曲线，好比分布方式下的代码同步，local branch的理解与运用，分布式代码管理的理解与运用等。详细的比较能够参考：这里。
2、大型分布式团队
曾经有这样一个分布式团队，他们在多个城市都有小分队，而且正在开发一个大型项目，见下图
他们使用的代码版本管理工具是第二代代码管理工具SVN，管理方案以下：
可是他们在使用的过程当中却遇到了下面这些问题与痛点。
因为是分布式团队，因此：
- 基于团队的代码模块分离困难
当服务器不可用时：
- 不能查看提交记录
- 不能比较文件
- 不能提交代码
建立代码分支时：
- 分支建立速度慢
- 多分支管理困难
在提交代码时：
- 但愿有Code Review
- 但愿有CI Review
由于代码庞大：
- 查看日志慢
备份代码库的时候：
- 须要停机备份
- 备份成本高
针对以上问题，可使用新一代的分布式的代码版本管理系统来解决，见下图：
其中每个团队都有本身独立的代码库，有一个中心库用于同步这些独立的代码库，而且每一个库都由团队本身管理和维护。并且代码版本管理系统须要支持轻量分支，代码评审，离线提交，离线查看日志等功能。
可是因为当前没有一个单一的代码版本管理工具能同时知足以上全部需求，因此不少公司都基于它们开发集成管理系统，好比Gerrit，GitLab，GitHub，BitBucket等。其中的Gerrit因为其开源，免费，以及由Google开发和维护，并管理着Android，OpenStack等大型项目源代码的特色，成为了大型分布式团队优先选择的系统。
3、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，见下图。
4、SVN到Git的迁移
对于想从集中式代码管理系统迁移到分布式代码管理系统的团队来说，若是团队规模小，那么问题通常都不大，可是对于大型分布式团队倒是困难重重。最主要的两个困难：
- 代码量太大，很难一次性将全部的代码和日志等在短期内迁移成功。
- 因为下属团队太多，很难同一时间让全部团队都切换至新的代码管理工具。
为了解决这些难题，通常都会首先选用1个团队来使用新的代码版本管理工具。若是这个团队转换成功，再将其做为标杆向其余团队推广，从而逐步的将全部团队切换到新的工具上去。
SVN到Git的迁移方案通常主要会使用两种工具：
- 开源免费的git-svn；
- 商业收费的Subgit。
其中使用Subgit的迁移方案以下图：
若是团队组资源充足，还可使用Gerrit搭建一个独立的Git服务器，从而以分布式的方式进行代码迁移，以下图：
5、多产品线的管理
使用同一个中心代码库管理多产品线一直是大型项目的一个困难点，特别是使用SVN这样的工具更是难以管理，由于SVN这种工具的Branch本质上是一个目录拷贝，而且速度慢，并且代码回迁也须要手动进行。可是若是使用Git的特性来管理多产品线，比起SVN是事半功倍。具体方案见下图：
总结：
分布式代码版本管理系统并不必定适合全部团队，好比中小团队可能更关心的只是成本更低，简单易用，那么SVN等这类集中式版本管理工具仍是更为适合。可是无论团队最终选用什么代码版本管理工具，只要适合本身的团队的开发流程和工做方式，而且代码管理顺畅就能够了。
文／ThoughtWorks刘冉
原文：大型分布式团队的代码版本管理 - ThoughtWorks洞见
转自：
https://link.zhihu.com/?target=http%3A//insights.thoughtworkers.org/code-management-of-large-distributed-team/
https://www.zhihu.com/question/25491925