GIT&SVN

GIT&SVN我带你快速了解GIT

目前Svn版本管理工具是中心库模式的版本管理且对分支的管理很不理想，对由企业、或者团队开发来说，我们团队将会越来越大，项目版本分支越来越多。对于Svn就不太适合这样的需求，因此我们将带你快速入门Git。下面我们总体介绍一下Git和Svn的区别及优缺点。

1、Git和Svn简介

1.1、Svn介绍

Svn是Subversion的简称，是一个开放源代码的版本控制系统,支持大多数常见的操作系统。作为一个开源的版本控制系统,Subversion管理着随时间改变的数据。这些数据放置在一个中央资料档案库(repository)中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本,或是浏览文件的变动历史。Subversion是一个通用的系统,可用来管理任何类型的文件,其中包括了程序源码。

集中式管理的工作流程如下图：

集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。

下面举例说明：

开始新一天的工作：

1、从服务器下载项目组最新代码。

2、进入自己的分支，进行工作，每隔一个小时向服务器自己的分支提交一次代码（很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了）。

3、下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。

1.2、Git简介

Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆（git clone），在本地机器上拷贝一个完整的Git仓库。

下图是经典的git开发过程。

Git的功能特性：

从一般开发者的角度来看，Git有以下功能：

1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。

2、在自己的机器上根据不同的开发目的，创建分支，修改代码。

3、在单机上自己创建的分支上提交代码。

4、在单机上合并分支。

5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。

6、生成补丁（patch），把补丁发送给主开发者。

7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决 冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。

8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

从主开发者的角度（假设主开发者不用开发代码）看，Git有以下功能：

1、查看邮件或者通过其它方式查看一般开发者的提交状态。

2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有 用，哪些不用）。

3、向公共服务器提交结果，然后通知所有开发人员。

2、Git和Svn异同

2.1、区别

Svn属于集中化的版本控制系统，有个不太精确的比喻:Svn = 版本控制+ 备份服务器，Svn使用起来有点像是档案仓库的感觉，支持并行读写文件，支持代码的版本化管理，功能包括取出、导入、更新、分支、改名、还原、合并等。

Git是一个分布式版本控制系统，操作命令包括：clone，pull，push,branch ,merge ,push,rebase，Git擅长的是程序代码的版本化管理。在Git 中的绝大多数操作都只需要访问本地文件和资源，不必联网就可以看到所有的历史版本记录，而SVN 却需要联网。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快，但我们需要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算。

Svn 断开网络或者断开VPN就无法commit代码，但是Git 可以先commit到本地仓库。用SVN的话，没有网络或者断开VPN时，你当然也可以继续在本地开发，但是无法commit代码，因为Svn 每次commit都必须联网，长时间不commit代码会丢失大量开发进程的历史纪录。有个比喻是：不能commit就像用word写文档不能save一样危险。而且有网络的情况下每一次commit都会花上数秒甚至更长时间。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，因为是在本地仓库commit所以几乎不需要时间，而且commit一定要频繁，不然无法记录你的改动，如果你一天commit一次，中间的修改你就找不回来，然后等到了有网络的时候再将版本纪录和代码一起上传到远程仓库。

2.2、优缺点

Svn对中文支持好，操作简单，使用没有难度，美工人员，产品人员，测试人员，实施人员都可轻松上手。使用界面统一，功能完善，操作方便。

Svn属于集中化的版本控制系统，这种做法带来了许多好处，特别是相较于老式的本地VCS来说。现在，每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。

Subversion原理上只关心文件内容的具体差异。每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容。

Subversion的特点概括起来主要由以下几条：

1.每个版本库有唯一的URL（官方地址），每个用户都从这个地址获取代码和数据；

2.获取代码的更新，也只能连接到这个唯一的版本库，同步以取得最新数据；

3.提交必须有网络连接（非本地版本库）；

4.提交需要授权，如果没有写权限，提交会失败；

5.提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类；

6冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。

Git对程序源代码进行差异化的版本管理，代码库占极少的空间。易于代码的分支化管理。不支持中文，图形界面支持差，使用难度大。不易推广。

Git属于分布式的版本控制系统,自2005年诞生于以来，Git日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统，可以应付各种复杂的项目开发需求。

与Svn不同，Git记录版本历史只关心文件数据的整体是否发生变化。Git并不保存文件内容前后变化的差异数据。实际上，Git更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git不会再次保存，而只对上次保存的快照作一连接。

Git 并没有像 Svn一样在每一次提交的时候都将更新的详细信息都分析并提交，这是很科学的，因为我们有90%的时候不会闲着要查看每一个文件都做了哪些更新，特别是模块化开发时，那些不是我们开发的模块，因为Git 会在本地保存完整的历史版本库，有十个用户共同开发就会有十份这样的库，这样做的话会会出现非常多冗余的数据。但是在Svn上这样还是科学的，因为只有Svn服务器上保存着唯一的一份历史版本库，当然是越详细越好了。但是当遇到那10%的时候，我们想要查看一下某个文件的与昨天的版本相比的更新变动信息，Git 会取出一天前的快照和当前文件作一次差异运算，显示出更新变动信息。

简略的说，Git具有以下特点：

1.Git中每个克隆(clone)的版本库都是平等的。你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。

2.Git的每一次提取操作，实际上都是一次对代码仓库的完整备份。提交完全在本地完成，无须别人给你授权，你的版本库你作主，并且提交总是会成功。

3.甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支。

4.Git的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库，合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成。

5.冲突解决不再像是Svn提交竞赛，而是在需要的时候才进行合并和冲突解决。

3、Git安装配置

在使用Git前我们需要先安装 Git。Git 目前支持 Linux/Unix、Solaris、Mac和 Windows 平台上运行。

Git 各平台安装包下载地址为：http://git-scm.com/downloads

在Git版本库目录中右键--->"TortoiseGit(T)"--->"设置"，添加Git远程库路径为先前创建的Gitlab项目Git路径。

4、Git使用

4.1、克隆获取项目

在本机任意目录下右键选择Git克隆

4.2、提交和推送

使用Git要学会要经常的commit到自己的本地仓库中，以避免代码丢失，随时还原自己的修改，在完成测试和调整后才合并提交推送到中心版本库。

4.3、本地创建分支及推送并创建合并请求

 

选择相应信息创建分支并切换。

完成开发后，提交并推送至线上，此时线上并不存在本地的对应分支，将会自动创建对应的分支。

4.4、合并冲突

协同开发不可避免的会出现合并冲突，当两个以上的开发人员对同一个文件进行修改后，总会有一个人先提交，另一个后提交，后提交的难免会遇到合并冲突。

 

例如上述情况，开发人员1和开发人员2均对bug1进行了修正，都提交了自己的分支，这时候比如先把开发人员1的合并进master分支是不会出问题的，当把开发人员2的分支要合并进master时，则会提示合并有冲突，merge按钮是灰色的不可操作状态。

点击MergeLocally，会提示怎么在本地进行合并操作

或者点击Resovle conflicts在线解决冲突

解决后填写提交信息，并点击提交即可

4.5、清理无效远程分支

远程服务器上的分支删除后，本地的远程分支并不会删除，这也从另一个角度说明了远程库和本地库都是独立的个体，但本地对远程分支进行fetch时，可以获取分支的更新或者新增新的分支，但却不会删除本地无效的远程分支，需要在本地获取的页面，选择清理，才可以清理掉这些无效分支。

4.6、本地分支删除

4.7、贮藏暂存

这种情况下要么你先提交到本地仓库，这是最直接的办法，但有时候你的修改明显还未结束，并不想提交到本地仓库，这种情况下就要用到Git的暂存区了。

这时候执行切换分支操作会出现错误要求提交你的操作

可以看到目前哪些修改还未提交

4.8、分支合并和变基

用Git进行多人协作开发时甚至是自己在本地为了某些需要也会利用分支实现，这时候必然会合并代码，解决冲突。然而合并代码也是需要点技巧的，如果对一些关键命令没有理解去使用的话，Git的版本演进路线就会变得很乱，从而造成了日后维护的一些麻烦。

 Git上合并代码有git merge 以及 git rebase 两种方式。

从左边的版本树可以很清晰的看到目前这个TestNew的分支并未完全同步或者说合并TestMain的提交修改。

如果我们需要同步TestMain分支的修改到TestNew（这种场景非常常见，开发人员要同步开发主线的功能更新到自己开发的功能 分支等），这时候为了将新的提交并入你的分支，你有两个选择：merge或rebase。

4.9、强制推送

在协同时，有时候会遇到远端Git库已经有人推送往前走了，但本地开发还是基于之前的提交版本进行开发的，这时候如果完成开发后进行远端推送会遇到冲突无法推送，这时候如果确保必须以自己的推送为准，舍弃远端分支上的某些后续推送，则可以采用强制推送的方式强迫远端Git分支按本地的分支往前走。

这种场景相对应用比较少，一般有如下几种：

1、个人认为一定要以自己的为准，不管别人是怎么开发的都不算数（这种要非常慎重）

2、不同远端Git库之间的同步备份，强制保持一致并避免推送错误

3、删除远端分支的某些错误提交，即重置远端分支的末端

4、同步修改远端分支的某些提交日志

当提示让我们先拉取后再提交，但这不是我们的目的，我们就是要强制修改

会到原来的推送页，强制上有两个复选，第一个代表如果远端分支和对应的跟踪分支则可以强制推送，第二个则代表即使远端分支不是对应的跟踪分支也仍旧强制推送（即比如master推送到远端的release，当然前提是master是由远端的master拉取获得的）。

5、小结

Git跟Svn一样有自己的集中式版本库或服务器。但Git更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上check out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。

事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。若是宕机一小时，那么在这一小时内，谁都无法提交更新、还原、对比等，也就无法协同工作。如果中央服务器的磁盘发生故障，并且没做过备份或者备份得不够及时的话，还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人提取出来。