从SVN到Git最强指南

对于软件开发人员来讲，版本控制系统他们再熟悉不过了，所谓版本控制系统就是软件项目开发过程当中用于储存开发人员所写代码全部修订版本的软件。它的主要目的是实现开发团队并行开发、提升开发效率，对软件开发进程中文件或目录的发展过程提供有效的追踪手段，保证在须要时可回到旧的版本，避免文件的丢失、修改的丢失和相互覆盖，从而减轻开发人员的负担，节省时间，同时下降人为错误。而目前常见的版本控制系统分为集中式版本控制系统和分布式版本控制系统两种。

SVN和Git

在集中式版本控制系统中，目前比较经常使用的是SVN，而提及SVN就不能不谈CVS，CVS是一个C/S系统，主要在开源软件管理中使用。多个开发人员经过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。CVS版本控制系统是一种GNU软件包，主要用于在多人开发环境下的源码的维护。可是因为CVS编码存在一些问题，大多数软件开发公司都使用SVN替代了CVS。SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上不少版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多我的共同开发同一个项目，共用资源的目的。

而在分布式版本控制系统中，Git逐渐占据了上风，目前，国外最大的社交编程及代码托管网站Github，Bitbucket，Gitlab，国内的码云、Coding、华为软件开发云（DevCloud）中的配置管理等代码托管平台均支持Git。Git是一款免费、开源的分布式版本控制系统，能够有效、高速的处理从很小到很是大的项目版本管理。Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了做为一种过渡方案来替代 BitKeeper，后者以前一直是Linux内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人以为BitKeeper 的许可证并不适合开放源码社区的工做，所以Torvalds决定着手研究许可证更为灵活的版本控制系统。尽管最初Git的开发是为了辅助Linux内核开发的过程，可是咱们已经发如今不少其余自由软件项目中也使用了Git。

而随着拥有分布式版本控制系统优点的Git的快速发展，愈来愈多的开发者准备从集中式版本控制系统SVN迁移到Git上，这其中，Git相对SVN表现出来的更有利于开发者版本控制管理的特色天然是最重要的缘由。

Git vs. SVN

由于从属于不一样的集中和分布式模式，所以，从工做模式来看，Git和SVN存在着比较明显的不一样，以下图所示。

集中式版本控制系统工做模型

分布式版本控制模型

从二者的工做模式能够看到，分布式相比于集中式的最大区别在于开发者能够提交代码到本地，每一个开发者经过克隆（Git clone），在本地机器上拷贝一个完整的Git仓库。而SVN则必须将代码提交到中心控制器。而由此产生的差别性，则决定了Git和SVN的各自的特性。

安全性

首先在安全性方面，因为采用分布式系统，每一个用户就至关于一个Git库的备份，同时，经过SHA1哈希保证数据的完整性，防止恶意篡改，所以，具备很高的安全性。而SVN因为采用集中式，所以，全部代码版本库均存储在中央服务器中，所以，存在很大的单点故障的风险，同时，当服务器端历史数据被篡改时，客户端难以发现。

分支功能

在分支功能方面，因为Git采用本质上指向Commit对象的可变指针，所以，便于查询和追溯分支间的提交历史，并可以支持双向合并。而SVN分支不支持提交隔离，虽然一次提交可同时更改主线和分支的内容，但没法查询和追溯分支间的提交历史。

发布控制

在Git中，能够设置只有发布管理员才有权限推送的版本库或者分支，用于稳定发布版本的维护，还能够设置只有项目经理、模块管理员才有权推送的版本库或者分支，用于整合测试，所以，发布控制至关灵活，而SVN并无明确的发布控制配置，更多的仍是依靠用户本身的习惯。

开发审核

在开发审核方便，Git支持团队成员自建分支和版本库。经过合并请求或从成员我的版本库、分支获取提交，从提交说明、代码规范等方面对提交逐一审核。而SVN则不具有这些功能。

合并支持

Git基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪，避免没必要要的冲突，提升了工做效率。而Git基于对内容的追踪而非对文件名追踪，因此遇到一方或双方对文件名更改时，可以很好进行自动合并或提供工具辅助合并。而SVN遇到一样问题时会产生树冲突，解决起来很麻烦。

所以，从以上的对比能够看出，Git相对于SVN具备很多的优点，所以，从SVN迁移到Git成为了众多开发者的选择。

从SVN到Git

那么，从SVN到底如何切换到Git呢？实际上，方法有不少种，也都并非很复杂，其中，CSDN博主UrChen提供了一种切换的方法，只须要简单的几步，便可完成从SVN完美切换到Git。

1.使用git svn clone 拷贝SVN仓库

cd ~/test_repo

git svn clone file:///home/*/Desktop/SVN/svn_repo/ -T trunk -b branches -t tags

2.新建一个Git的bare仓库

cd ..

mkdir test.git

cd test.git

git init --bare

3.将Git的默认分支和SVN的默认分支trunk对应起来

git checkout trunk

4.将test_repo推送到test.git中

cd ~/test_repo

git remote add bare ~/test.git

git push bare

此时就完成了推送，能够删除test_repo了

5.将Git repo中的trunk重命名为master

cd ~/test.git

git branch -m trunk master

6.将SVN repo中的tags移动到git repo的相应位置

使用git svn clone导出版本库的时候会将svn中的tags保存成git中的tags/**，而并非默认的tag，因此要进行移动。（注意：此脚本仅示例tag是单级目录的状况，若是 tag 是包含目录的两级或者多级tag，请自行从新撰写脚本）

cd ~/test.git

git for-each-ref --format=´%(refname)´ refs/heads/tags |

cut -d / -f 4 |

while read ref

do

git tag "$ref" "refs/heads/tags/$ref";

git branch -D "tags/$ref";

done

7.完成迁移，获得test.git

进入工做文件夹，执行

git clone ~/test.git

OK，大功告成，使用Git进行版本管理吧。

除此以外，还有几个问题须要说明：

一、经过git-svn工具能够在SVN迁移到Git上，保留仓库历史记录。

二、切换到Git后推荐策略建议采用长期分支、特性分支。

三、目前Git还无法作到像SVN中对特定文件夹的细分权限控制，但可经过分仓或创建多分支的方式引导用户使用。

四、切换到Git后遇到合并冲突时，分两种状况：

类型1：修改了同一个文件的同一行

解决方法：确认正确的修改，而后用命令行解决，示例以下：

类型2：文件被重命名为不一样的名字（树冲突）

解决办法：确认哪一个名字是正确的，删除错误的，示例以下：

DevCloud与Git

前面已经说过，华为软件开发云（DevCloud）中的配置管理服务全面支持Git，并对Git进行了全面优化。而实际上，这个配置管理服务就是面向软件开发者提供的基于Git的在线代码托管服务。对于管理员和项目经理，它提供了仓库管理、权限管理、成员管理、分支保护、安全管控及统计服务，对于开发者，它则提供了代码托管、代码仓库、在线客户端等服务。配置管理服务的产品架构图，以下图所示：

DevCloud的配置管理服务对Git的优化主要体如今如下几点：

1）支持跨地域协同开发、本地离线操做、代码合入评审。

2）支持在线客户端、代码在线浏览、修改、提交、在线建立分支、比较分支、新建合并请求。

3）具备代码加密传输、仓库权限管理、分支保护等多种安全措施。

4）提供了大量的仓库模板、通用模板，以方便开发者提升建立效率。

5）提供基于代码的统计分析、仓库提交信息统计、贡献者统计等相关统计数据。

总结

总之，从SVN切换到Git目前来看，是利多弊少，也是一个趋势，建议有条件的开发人员能够尝试一下，此外，DevCloud中的配置管理针对开发人员使用Git作了大量的优化工做，感兴趣的朋友也能够登陆http://www.hwclouds.com/devcloud/网站下载试用，体验一把用优化了的Git进行版本控制的感觉！