大话GIT之版本管理简介

1 版本管理是什么

相信大家在玩游戏的时候，都有这样的体验，比如游戏有5个关卡，大杠同学第一天就过了3关，非常开心，但是第二天要上班，就会保存游戏进度，等到下次的时候再继续，然后第二次又过了1关到了第4关，马上就要通关了，这个时候大杠在官网发现第3关还有隐藏彩蛋没有体验到，于是保存了第4关，把游戏进度设置为第3关，重新打怪升级，毕竟花钱买的游戏，一定要榨干每一个体验，但是玩着玩着，发现第3关的新玩法玩不下去了，大杠同学很烦，不想在第3关继续浪费时间，但是又有些遗憾，希望通关后再重新来试一下，于是又保存了第三关的闯关记录，到这里，大杠同学已经保存了3个记录，第3关两个，第4关一个，这里每一个记录我们可以堪称一个版本，方便使用者来回切换，回到工程师的角度，在日常研发工作中也需要对代码有一个进度设置和切换，也就是所谓的版本管理。

2 为什么要用版本管理

在工程师的日常研发工作中，在同一时间会面对下面情况。大杠同学刚来公司，就得到团队领导的器重，让他单独负责订单服务的研发工作，恰好这个时候产品同学想试试大杠的研发能力（脾气好不好），方便以后讨论需求（加需求QAQ），于是，立马提出了一个订单查询优化的需求，大杠刚来，非常实诚，吭哧吭哧一天就把活干完了，当产品问进度的时候，也如实相告，产品一听，内心的小算盘打起来，正好业务最近反馈订单缺少一个报表，不方便每月将订单发生额和增长反馈给老板，每次都需要手动统计，这可是一个像业务方表现的机会，产品想着今年的绩效得提一提，于是马上将这个需求提给了大杠同学，这个时候，大杠同学有些为难了，不是因为需求来了，而是订单查询优化这个需求还没发布，如果这个时候又开始进行新的功能开发，那么两个需求就耦合在一起了，但是两个需求的发布时间又不是一样的，这个时候就需要一个版本管理工具，先把订单优化需求的代码保存起来，然后将代码版本切换到原代码（目前线上使用的代码），再进行报表能力开发，当到了发布日的时候，再将版本还原到订单优化这个版本，进行上线发布，这里就涉及到了版本的设置和切换，也就是说在日常研发工作中，无法避免需求并发的情况，或者临时需要修复线上问题，这个时候就需要控制代码版本，方便代码和需求绑定，需求和需求，代码和代码之间解耦，避免互相影响，同时也方便问题排查。

3 版本管理模式有哪些

3.1 本地版本管理

本地版本，顾名思义就是在本地进行版本控制，对每一个版本生成一个版本号，方便个人进行版本的来回切换，优点是实现了个人对文件的版本控制，缺点是没办法进行团队协作，比如大杠同学和团队的其它成员一起完成报表开发，大杠负责报表数据拉取，生成，团队中另外一个同学负责报表的下载和发送，那么当大杠完成了相关代码的开发，是没有办法将已完成版本给到合作的同学的，就会导致代码合并困难，需要人工处理，容易出现问题，合作风险提高，也就是说团队成员没有办法参与到当前版本的开发当中来

3.2 集中式版本管理

集中式版本管理，就是在远程有一个版本管理仓库，大家都可以通过远程版本库对当前文件进行管理，优点是解决了团队版本协作的问题，缺点是一旦远程版本管理工具出现问题，就容易单点故障，团队无法进行版本协作，影响项目进度，同时一旦远程数据丢失，那么团队的努力都会付诸东流，比如大杠将报表的字段定义好后，然后将版本推送到远程，这个时候，合作同学就可以通过远程拉取最新的版本，然后根据定义好的字段进行功能开发，但是如果远程版本管理工具出现了故障，那么大杠就无法推送版本，其他人也无法拉取版本，团队工作将会陷入停滞。同时，如果远程版本服务器一旦发生数据丢失或者被破坏，对团队来说，将是毁灭式打击。

 3.3 分布式版本管理

分布式版本管理解决了本地版本管理中无法团队协作和集中式版本管理单点故障的问题，因为在分布式管理当中，既有本地版本管理的能力又同时拥有远程版本管理的能力，比如，大杠同学将报表字段定义好后，然后再本地保存一个版本，同时将版本推送到远程版本库，就开始开发报表拉去功能，开发到一半，其它同学反馈，远程版本库出现异常，版本数据丢失，拉取不到已经定义好的报表字段，这个时候，小杠心里咯噔一下，情绪立马就恢复了正常，因为他再本地已经保存好了之前的版本，只要将版本切换回去，等远程仓库恢复正常后，再将版本推送过去就好。

4 版本管理组件有哪些

国内常用的主要是GIT，以前会有SVN，但基本上是过去式，所以目前主流的版本管理组件就是GIT，一个分布式版本管理组件