简介
当前，大多数开发中的开源项目以及大量的商业项目都使用 Subversion 来管理源码。作为最流行的开源版本控制系统，Subversion 已经存在了接近十年的时间。它在许多方面与 CVS 十分类似，后者是前者出现之前代码控制世界的霸主。
而在分布式版本控制系统中，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 再去学习其他的版本控制相对容易，所以我个人也很偏向大家先开始学习Git。
对Git的基础学习可以参考：https://blog.csdn.net/qq_33285292/article/details/83026328
今天的正题是如何在Git中管理SVN库，在Git官方文档中有明确的说明了使用 git svn 命令，接下来让我们来详细了解下该命令。
git svn
Git 中所有 Subversion 桥接命令的基础是 git svn 。所有的命令都从它开始。相关的命令数目不少，你将通过几个简单的工作流程了解到其中常见的一些。值得警戒的是，在使用 git svn 的时候，你实际是在与 Subversion 交互，Git 比它要高级复杂的多。尽管可以在本地随意的进行分支和合并，最好还是通过衍合保持线性的提交历史，尽量避免类似与远程 Git 仓库动态交互这样的操作。避免修改历史再重新推送的做法，也不要同时推送到并行的 Git 仓库来试图与其他 Git 用户合作。Subersion 只能保存单一的线性提交历史，一不小心就会被搞糊涂。合作团队中同时有人用 SVN 和 Git，一定要确保所有人都使用 SVN 服务来协作——这会让生活轻松很多。
从SVN中克隆
命令格式：git svn clone <svn仓库路径> [本地文件夹名] [其他参数] 相当于git clone
示例： git svn clone svn://xxxx/svn_project E:\IDE\svn_project
参数说明：
-s告诉 Git 该 Subversion 仓库遵循了基本的分支和标签命名法则，也就是标准布局。
如果你的主干(trunk，相当于非分布式版本控制里的master分支，代表开发的主线），分支(branches)或者标签(tags)以不同的方式命名，则应做出相应改变。-s参数其实是-T trunk -b branches -t tags的缩写，这些参数告诉git这些文件夹与git分支、tag、master的对应关系。--prefix=svn/给svn的所有remote名称增加了一个前缀svn，这样比较统一，而且可以防止warning: refname 'xxx' is ambiguous.
获取SVN更新内容
命令格式：git svn rebase
一般没有切换分支默认是直从mater获取
提交到SVN
一般来说我个人推荐这样做：
先执行：git commit -m “说明”
在执行：git svn dcommit
这样做是先提交到本地仓，在统一提交到SVN，原因就是当你还在编码时你的团队要运行项目的时候会运行不起来，当然这个也可以用分支来解决这个问题，当让保存文件后也可以直接提交到SVN上，但是这种方式不推荐。
冲突解决
如果本地和svn都进行了修改，则不能快速前进，git svn rebase 会出现错误。
这时应该按以下步骤操作：
-
手动修改冲突文件，修改完成后
git add -
git rebase --continue -
git svn dcommit
SVN分支管理
新建分支到svn
命令：git svn branch <分支名称>
示例：git svn branch c_by_git
说明：在svn仓库上建了了一个c_by_git分支
分支情况
* master
remotes/svn/a
remotes/svn/trunk删除svn分支
- 删除svn分支目录
svn rm <svn分支路径> -m <commit信息>
示例：svn rm svn://xxx/svn_repo/branches/c_by_git -m 'rm branch' - 删除远程跟踪分支
git branch -D -r <远程分支名称>
示例：git branch -D -r svn/a
SVN上tag管理
新建tag
命令：git svn tag <tag名称>
示例：git svn tag v1.1
说明：在svn仓库上建了一个v1.1tag
删除tag
-
删除svn目录
svn rm <svntag路径> -m <commit信息>
示例：svn rm file:///d/Projects/svn_repo/tags/v1.1 -m 'rm tag' -
删除远程跟踪分支
git branch -D -r <远程分支名称>
示例：git branch -D -r svn/tags/v1.1
说明：svn的tag和分支在git看来是一样的，所以此处还是用的git branch
SVN 日志
同样，它不显示本地的 Git 提交以及 Subversion 上后来更新的内容。类似 git svn log 对 git log 的模拟，svn annotate 的等效命令是 git svn blame [文件名]。其输出如下：
$ git svn blame README.txt
2 temporal Protocol Buffers - Google's data interchange format
2 temporal Copyright 2008 Google Inc.
2 temporal http://code.google.com/apis/protocolbuffers/
2 temporal
22 temporal C++ Installation - Unix
22 temporal =======================
2 temporal
79 schacon Committing in git-svn.
78 schacon
2 temporal To build and install the C++ Protocol Buffer runtime and the Protocol
2 temporal Buffer compiler (protoc) execute the following:
2 temporal同样，它不显示本地的 Git 提交以及 Subversion 上后来更新的内容。
SVN 服务器信息
还可以使用 git svn info 来获取与运行 svn info 类似的信息：
$ git svn info
Path: .
URL: https://schacon-test.googlecode.com/svn/trunk
Repository Root: https://schacon-test.googlecode.com/svn
Repository UUID: 4c93b258-373f-11de-be05-5f7a86268029
Revision: 87
Node Kind: directory
Schedule: normal
Last Changed Author: schacon
Last Changed Rev: 87
Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009)
它与 blame 和 log 的相同点在于离线运行以及只更新到最后一次与 Subversion 服务器通信的状态。