SVN与Git

今天来统一了解一下SVN和Git的知识，

SVN

SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的。一个人开发的时候，也可以用SVN来管理版本，保存记录，方便查找某个时间的代码，同时也相当于备份，免得一方出现问题，还可以找另一方的代码。

工作流程

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

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

开始新一天的工作：

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

2、进入自己的分支，进行工作，每隔一个小时向服务器自己的分支提交一次代码（很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了，不过我自己开发习惯的方式是把一个小版块都写完了，测试好了，在上传代码到SVN上，这样避免一些冲突和无形的bug，还是测试好再上传更好一点）。

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

这就是经典的svn工作流程，从流程上看，有不少缺点，但也有优点。

缺点

1、服务器压力太大，数据库容量暴增。

2、如果不能连接到服务器上，就不能提交，还原，对比等等。基本上算是不可以工作。

3、不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。

优点

1、管理方便，逻辑明确，符合一般人思维习惯。

2、易于管理，集中式服务器更能保证安全性。

3、代码一致性非常高。

4、svn可以离线开发，比如可以带回家继续开发，回来后，提交就行了。

4、适合开发人数不多的项目开发。

5、大部分软件配置管理的大学教材都是使用svn和vss。

SVN在AndroidStudio中的使用

作者：夏海亮，链接：https://www.zhihu.com/question/32298079/answer/56010423，来源：知乎

一、Android Studio配置SVN

Android Studio关联配置SVN很简单，在Settings里面，找到Version Control->Subversion；在这个页面的控制面板中的General中将Use command line client打勾勾选上，然后浏览本地的SVN安装目录，选到"\svn.exe"即可；
在Use command line client下面还有一个Use system default Subversion configuration directory，这个默认是勾选上上的，这个是svn相关配置信息的路径，保留默认路径就行，目前没有发现需要修改什么东西；以上操作如下图：

       二、Android Studio项目关联SVN资源库及添加忽略文件

在Android Studio中新创建一个Android项目，成功后我们先来添加要忽略的文件；在Android Studio中添加忽略文件同Eclipse有所不同，在Eclipse上我们什么时候添加忽略文件都可以，但是在Android Studio中只有在未关联SVN之前添加忽略文件才有效。Android Studio添加忽略文件同样是在Settings->Version Control（跟版本控制有关的设置都在这个目录下）下的Ignored Files里，点击加号进行忽略文件的设置，Android Studio默认给出了三种忽略方式，供开发者进行选择：忽略指定的文件、忽略文件夹下所有文件和忽略符合匹配规则的文件；如图所示：

点击右侧的“+”进行添加，“-”删除；Android Studio创建的Android项目一般需要忽略.idea文件夹、.gradle文件夹、所有的build文件夹、所有的.iml文件及local.properties文件。
忽略完文件后，我们进行项目同SVN的关联，选择VCS->Import into Version Control->Share Project(Subversion)；这里说明一点，在Import into Version Control下有Import into Subversion和Share Project(Subversion）两个选项：第一个是直接将项目导入到SVN服务器上，但是这样做本地的项目同SVN服务器没有建立起关联，在导入后项目所有的文件都会变成红色，而且在要提交到SVN服务器时会提示项目不是SVN下的工作副本；第二个是将Android Studio当前项目同SVN服务器关联起来，但是并没有将项目导入到SVN服务器上，需要在完成建立连接后再次提交项目到SVN服务器。两种方式都可以实现将本地代码提交到SVN服务器的功能，但是步骤有所不同，先来完成第二种方式的项目同SVN的关联及代码提交，第一种貌似不正规，之后再说；下图既是第二种方式将本地项目同SVN进行关联的：

之后会弹出选择要分享的SVN地址及其他选项，如下图：

在Define share target下选择第二个可以再trunk下创建你当前项目的文件夹，相应的第一个选项是直接将整个文件都放到trunk文件夹下，第三个在项目文件夹下有创建了一个trunk文件夹，因此建议使用第二中方式；选择完成后点击Share就可以了，会弹出让你选择SVN工作副本的格式化版本（jdk版本），如下图：

建议选择1.8format，我之前选择了其他的试了一下，发现项目总会报出一下错误，原因暂时未发现，就先这样选择吧；点击OK等待一会就能创建本地项目同SVN服务器的关联了；成功后悔自动刷新本地的项目，待项目里的内容变成绿色的即表示已经成功了，如下图所示：

到目前为止只是将项目同SVN服务器建立了联系，并没有将代码提交到SVN服务器上去；如何提交呢，其实很简单，只需点击SVN相关操作按钮里的commit就行了（上图SVN相关操作按钮左起第二个按钮）；

点击Commit后Android Studio会先对当前代码进代码分析，如果有错误或者警告会弹出如下的框，如果有错误冲突等需要解决后再提交，如果是警告可以忽略（同Eclipse相同）；第一次将整个代码提交到SVN服务器时时间有可能很长，请耐心等待，之后再创建项目时就不会这么慢了。

成功后我们就完成了新建项目同SVN的关联及导入项目到SVN服务器上了。
关于第一种方式，在将本地代码导入到SVN服务器后将本地代码删除，然后从SVN服务器上将之前提交的代码更新下来，这样一来也可以同SVN建立关联正常进行开发；第一种方式和第二种方式的区别就在于：第一种是将代码先提交到SVN服务器上，然后再从SVN服务器上更新下来（本地项目同SVN服务器建立联系）；第二种是先同SVN服务器监理联系，然后将代码提交到SVN服务器上去。建议使用第二种方式进行新项目的SVN关联。

如果不建立忽略文件，那么每次提交的时候就不要点击直接提交的按钮，而是只提交更改的代码部分，其他文件就不用管了，如图：

选中要提交的文件右键

 然后弹出对话框，选中你更改的文件，然后提交

其他可能遇到的问题，上面已经说过解决。

这是我开发喜欢用的方式，Android开发，基本上就提交java文件，res下的文件。

三、Android Studio SVN代码冲突的解决

在使用SVN更新服务器上的代码时，有时会弹出代码冲突的对话框，问你是否进行合并，并提供了三种合并方案：accept yours(使用你的)、accept theirs(使用别人的)和merge(合并)；

前两个都是进行的覆盖操作，就不多做解释了；当你选择merge合并时，会弹出代码合并对照窗口，一共有三个屏，左右两侧是你和服务器不同的代码并高亮显示不同的部分，带有箭头和叉号，通过点击箭头将两边冲突的代码添加到中间的合并区域中去，点击叉号则辨识放弃那一段代码，待所有冲突处理完成后merge就成功了。

Git

特点
分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆（git clone），在本地机器上拷贝一个完整的Git仓库。
下图是经典的git开发过程。

Git的功能特性：
从一般开发者的角度来看，git有以下功能：
1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。
2、在自己的机器上根据不同的开发目的，创建分支，修改代码。
3、在单机上自己创建的分支上提交代码。
4、在单机上合并分支。
5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6、生成补丁（patch），把补丁发送给主开发者。
7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

从主开发者的角度（假设主开发者不用开发代码）看，git有以下功能：
1、查看邮件或者通过其它方式查看一般开发者的提交状态。
2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。
3、向公共服务器提交结果，然后通知所有开发人员。

优点：
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
离线工作。

缺点：
资料少（起码中文资料很少）。
学习周期相对而言比较长。
不符合常规思维。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

Git 和 SVN 之间的五个基本区别

原文地址：http://blog.jobbole.com/31444/

Git不仅仅是个版本控制系统，它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN背景的人，你需要做一定的思想转换，来适应GIT提供的一些概念和特征。所以，这篇文章的主要目的就是通过介绍GIT能做什么、它和SVN在深层次上究竟有什么不同来帮助你认识它。

1.GIT是分布式的，SVN不是：

     这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。

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

     同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。

2.GIT把内容按元数据方式存储，而SVN是按文件：

所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。

3.GIT分支和SVN的分支不同：

分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。

然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。

4.GIT没有一个全局的版本号，而SVN有：

目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线索，请在评论里奉献出来与大家共享。

更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。

5.GIT的内容完整性要优于SVN：

GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论 –http://stackoverflow.com/questions/964331/git-file-integrity

GIT和SVN之间只有这五处不同吗？当然不是。我想这5个只是“最基本的”和“最吸引人”的。

github

 

GitHub 是一个面向开源及私有软件项目的托管平台，因为只支持 Git 作为唯一的版本库格式进行托管，故名 GitHub。