从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存在着比较明显的不同，如图1所示。

  集中式版本控制系统工作模型 分布式版本控制模型

 

  从两者的工作模式可以看到，分布式相比于集中式的最大区别在于开发者可以提交代码到本地，每个开发者通过克隆(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进行版本管理吧。

  除此之外，还有几个问题需要说明：

  1、通过git-svn工具可以在SVN迁移到Git上，保留仓库历史记录。

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

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

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

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

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

  类型2：文件被重命名为不同的名字(树冲突)

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

  DevCloud与Git

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

  DevCloud的配置管理服务对Git的优化主要体现在以下几点：

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

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

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

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

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

  总结

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