版本管理工具之于软件开发，犹如地基之于建筑。这句话真是再贴切不过了，当项目越做越大，迭代越来越频繁，版本管理工具变得越来越具有必要性。

    有了版本管理工具，我们可以更方便地浏览、检出所有开发过程的历史版本与修改记录，做任何修改都不再害怕，因为你可以轻易的复原回任意一个版本并且知晓每一次修改的原因。甚至你可以从历史版中单独抽出某一次修改，将它放到另一个版本中。

    我们也可以通过版本管理工具来同时并行修改和发布软件的不同版本，例如公测版本、付费版本和开发中版本。

    选择一款版本管理工具，已经被大多数企业作为项目的必要准备工作之一，相信没有一个开发者没有听过Git、SVN这些工具。

    今天我们来寻根溯源，扒一扒版本管理的发展史。

版本管理发展史

    上图是版本管理发展史的里程碑图，下面我们将其分成四个阶段详细来说说。

史前时代 手动备份

    在修改文件之前将它手动备份一份，名称做上标记，这就是最早的版本管理。

手动备份的存在，说明了人们需要版本管理工具。

农耕时代 本地版本管理工具

    如同农耕时代的信息闭塞一样，第一批产生的版本管理工具被称为本地版本管理工具，它们只被赋予在一台服务器上管理文件版本的能力，并不具备联网、交互的特性。

    其中比较有代表性的是1982 年由米国普渡大学的 Walter F. Tichy 首次发布的RCS（Revision Control System），它比Linux的内核发布还要早9年，最初是为了替代世界上第一款版本管理软件（SCCS，1972，用于Unix系统）所研发的，起初RCS只应用在Unix系统，而后移植到Linux平台，甚至还有应用于Windows平台的可执行程序。

    虽然它们已经渐渐被人们淡忘，但是毕竟是版本管理领域的文明启蒙之作，如今你仍能从各大开源网站找到它们的源码。

    这个时代也产生了锁的概念。

通过加锁可以将并发提交转换成顺序提交，避免了同一文件被多人同时修改，这也是最初的版本控制手段之一。

帝国时代 集中式版本管理工具

    集中式版本管理工具的特点是，用一个服务器来保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，下载最新的代码或是更新提交，这像极了中央集权制的帝国时代。

    其缺点很明显，就是如果服务器挂了，所有参与者都无法工作了，并且工作成果有可能就此丢失。

    但是集中式版本管理工具的出现，解决了软件行业遇到的第一个史诗级问题——跨地域协同开发。

    有问题，就会出现解决问题的英雄，一位名叫 Dick Grune 的荷兰科学家在 1986 年开发了一款名叫CVS（Concurrent Versions System）的版本管理工具，这是世界上第一款集中式版本管理工具，它的设计初衷就是解决跨地域协同开发带来的不便。

当时Dick和他的两名学生正在合作完成一个编译器项目，一个学生是朝九晚五的稳定工人，另一个学生的时间是不规律的，而Dick本人只能在晚上做这个项目，显然三个人没法坐到一起完成项目，为此Dick在RCS的基础上研发了CVS。

    CVS曾是世界上最为流行的版本管理软件，这种情况持续了十余年，直到 2000 年被 Subversion（SVN） 所取代。

    SVN设计的目的就是创建一个更好用的版本管理系统以取代 CVS，比较有趣的是，SVN在研发初期是使用CVS来管理其源代码的，并且其主要研发者是CVS畅销书《Open Source Development with CVS》的作者Karl Fogel，Karl和他的朋友Jim Blandy在CollabNet公司的资助下从2000年2月开始研发SVN，用了14个月的时间，终于在2001年8月31号让SVN 可以“自我寄生”了，就是说，SVN开发人员停止使用CVS管理 SVN的源代码，开始使用SVN代替。

    2010 年 1 月，SVN正式成被 Apache 软件基金会接收，并成为一个顶级项目，如今（2020年）SVN仍然是集中式版本管理工具中的江湖扛把子。

    SVN也是首创使用分支系统的版本管理软件，虽然其起初仅能将所有文件备份做为一个分支，但也对今后版本管理软件的发展产生了深厚的影响。

分支，可以理解为一个项目中平行存在的几套代码，它们可以彼此独立被修改，也可以被合并。

共产主义时代 分布式版本管理工具

    分布式版本管理系统的最大特点就是客户端并不只从服务器提取最新版本的文件快照，而是把仓库完整的镜像下来，包括了完整的历史记录。

可以这样理解，每个客户端其实都可以当做是中央服务器。

    这种运作模式带来的优势不仅仅是当中央服务器挂掉了、数据损坏了，从任何一个本地客户端都可以重新恢复。还可以允许开发者在飞机、游轮这种没有网络的环境下编程时，先将工作内容提交到本地仓库，等有网络条件时再合并到远程仓库。

    分布式版本管理工具已经基本剔除了锁的限制方式，允许项目参与者随时拉取中央仓库内容到本地仓库，在本地库自由开发，而只将对项目有贡献的修改合并回中央仓库，这种模式在开源项目中被利用到了极致，每个参与者都会感觉自己就是项目拥有者，开源项目的托管平台俨然就是一个迷你的共产主义社会。

    Git可说是世界上最先进的分布式版本管理系统（没有之一）。

    Git的诞生充满了传奇色彩，其作者正是李大神 Linus Torvalds（Linux之父）。

    Linux开源项目的初期，世界各地的志愿者把源代码文件发给Linus，然后由Linus本人通过手工方式合并到Linux源码中，这种情况持续了十多年（1991~2002），代码库的几何式增大让Linus很难继续通过手工方式管理了，于是Linus选择了一个商业化的版本管理系统BitKeeper（世界上第一款分布式版本管理软件，当时唯一的缺点就是 贵！），BitKeeper的东家BitMover公司也出于人道主义精神，授权Linux社区免费使用这个版本管理系统。

    直到2005年，Linux开源社区的一位参与者破解了BitKeeper的协议，被BitMover公司发现了，于是BitMover公司怒了，收回了Linux社区的免费使用权。由于倡导开源精神的Linus瞧不上集中式的CVS、SVN，又买不起BitKeeper，迫不得已开始研发自己的版本管理工具，并命名为Git（英国俚语，讨厌鬼），用Linus自己的话说：

关于Git的具体研发时间，有人说是两周，也有人说是两个月，其实都不准确，下面是文献记载的Git诞生里程碑。

• 2005 年 4 月 3 日，开始开发 Git。

• 2005 年 4 月 6 日，项目发布。

• 2005 年 4 月 7 日，Git 就可以作为自身的版本管理工具了。

• 2005 年 4 月 18 日，发生第一个多分支合并。

• 2005 年 4 月 29 日，Git 的性能就已经达到了 Linus 的预期。

• 2005 年 6 月 16 日，Linux 核心 2.6.12 发布，那时 Git 已经在维护 Linux 核心的源代码了。

    而后Git迅速成为世界使用量第一的版本管理软件，尤其是到2008年，诞生了首个伴生开源社区GitHub，更是让更多的人了解和开始使用Git。

中国开源社区主要创始人、华为高级产品经理庄表伟老师在《从28万个开源项目中，我们能够学到一些什么？》一文中也多次提到:“Git的统治地位，已经无可动摇”。

为什么更多人愿意选择Git？

    那么，开发者愿意使用Git作为他们的版本管理工具，仅仅是因为它出身名门么？多少会是有一些影响的，你想啊，生而为了管理Linux这种操作系统级别的项目，还有什么项目是它搞不定的呢。

    但是更多睿智的开发者看中的是Git的特质：

• 分布式：

  这使得服务器的压力不会很大，客户端也被赋予了更多权限，可以拉取全量代码、历史，离线工作等。

• 将分支的使用发扬光大：

  相比于SVN，Git采用快照的形式存储分支，并用指针方式完成切换，这使得切换变得非常的迅速，并且允许服务器与各个客户端都可以有自己独立的分支。

• 在本地解决代码冲突：

  Git不允许将有冲突的代码段提交到服务器，它倡导开发者将差异代码拉取到本地，并提示开发者差异位置，在本地解决、合并后，再提交到服务器，这不仅对于开发者来说是个最好的解决方案，同时也保证了服务器中代码版本的稳定性。

• 可以很简单，也可以很复杂：

  Git提供了丰富的指令集来实现几乎你能想到的所有功能，但是上手却非常简单，新手只要知道clone、add、commit就能完成基本工作流，高手又可以用复杂的指令组合展现出真正的技术！

• 永久免费：

  这个其实也蛮重要。

Git也有缺点！

    金无足赤，白璧微瑕，Git虽然是公认的王者，但是也不是没有缺点，我们来看下Git跟天下第二SVN的对比。

    可以看到Git在运作机制和具体功能实现上都是略胜一筹的，但其富有开源精神的血统决定了其在权限管理方面的薄弱，Linux对Git的设计就是，任何人都能拉取代码仓库，而且是全量的拉取，也包括了仓库的历史记录和历史版本，这在开源项目中实在是个很酷的设定，但在商业项目中，这难道不是一个Bug？

华为云CodeHub服务弥补了Git的缺点

    很多组织都很欣赏Git的优秀，同时也发现了Git在权限控制方面的薄弱，纷纷发布了基于Git的代码托管平台，就如同为Git打造的甲胄，其中值得一提的是华为云打造的代码托管（CodeHub）平台。

    这身红色的盔甲，沉淀着了华为在信息安全领域近30年的探索，下面我们来看看CodeHub目前已知的权限控制与安全策略：

• 采用“租户+用户+用户组+角色”多维度模型对权限进行颗粒化控制。

• 用户需通过HTTPS/SSH与云端仓库通信，将使用SSH Key或者仓库用户名及密码进行访问鉴权。

• 所有操作都必须带有Token，对所有关键操作进行审计记录，审计日志被持久化，可保留足够长时间，并可进行精确的回溯。

• 用户的托管文件是以加密的方式存储的。

• 支持保护分支的设置。

• 提供了多人参与、评分制的代码合并评审组件。

    简单来说，CodeHub将用户的读写权限变成了可控可配置的，它补上了Git的最后一块短板。

CodeHub服务还能做什么？

↓↓↓↓↓~给求知者的传送门~↓↓↓↓↓

• 丰富的代码模板

• 可自定义的代码提交规则

• 代码提交与项目任务状态可产生联动

• 积分制的Code Review

• 代码提交自动触发DevOps流水线

• 在线代码检查

• 在浏览器里Coding

• 数据分析

• 跳过那些磨磨唧唧的，直接去创建一个仓库试试~

丰富的代码模板

华为云代码托管服务针对不同的开发语言、构建环境，预置了数十个仓库模板，开发者可以使用模板在云端创建仓库，达到快速初始化研发环境的效果。

针对正在学习软件开发的同学们，也提供了丰富了的Demo源代码，可直接拿来学习，或者用于体验在CodeArts中的DevOps全流程。

了解更多

另外，支持用户将自己的仓库共享为模板。

可自定义的代码提交规则

华为云代码托管服务支持对每个仓库设置不同的代码提交规则，保证了中央库的代码规范性，为团队素质建设保驾护航。

了解更多

代码提交与项目任务状态可产生联动

华为云代码托管服务可以将代码的变更与项目管理中的工作项（需求单、问题单）相关联，而自动改变工作项的状态。

也就是说，开发者只需要提交代码，问题单就能自动流转，这大大地提升了协作效率，将开发者从繁杂的工作流程里解救出来，使其更专注的投入编码中。

了解更多

积分制的Code Review

    代码评审的价值不仅仅是集思广益，避免bug、提升代码质量、寻求更优的解决方案，还可以通过这个过程让每个项目参与者了解更多的业务模块，同时也能达到人员互备的目的。

    华为云代码托管服务提供了积分制的在线Code Review功能，项目参与者可以在评审中进行打分、评论、发起讨论等操作，总积分可以作为一个标准，团队达成共识后，方可进行下步的合入分支等操作。

    评审意见的记录，也使得团队成员在需要了解项目历史时，可以更方便的顺着代码、顺着提交记录与讨论记录解到当时发生了什么。

了解更多

代码提交自动触发DevOps流水线

作为华为云CodeArts的组成服务之一，代码托管服务可以被作为云上DevOps的触发器使用。

了解更多

在线代码检查

华为云代码托管服务会自动识别仓库语言，并生成对应的检查报告。

在仓库管理管理页面就能看到仓库的代码健康度，点击更能看到详细的代码检查报告。

了解更多

在浏览器里Coding

华为云代码托管服务内置了Cloud IDE功能，开发者可以在浏览器中Coding。

大大提升了开发者对紧急任务的响应速度，让敏捷开发模式更加得心应手。

了解更多

数据分析

华为云代码托管服务提供了多维度的数据分析报表（代码贡献度统计、仓库语言统计、提交统计、仓里提交网络图等），帮助仓库管理者了解研发工作的推进情况。

了解更多

如果您正在寻找一个靠谱的版本管理平台，不妨到华为云代码托管（CodeHub）服务创建一个仓库试试，5人以下使用免费哦~