参照 https://www.cnblogs.com/h2zZhou/p/6136948.html
命令格式：git svn clone <svn仓库路径> [本地文件夹名] [其他参数] 相当于git clone 示例： git svn clone file:///d/Projects/svn_repo proj1_git -s --prefix=svn/
1.-s 告诉 Git 该 Subversion 仓库遵循了基本的分支和标签命名法则，也就是标准布局。 如果你的主干(trunk，相当于非分布式版本控制里的master分支，代表开发的主线），分支(branches)或者标签(tags)以不同的方式命名，则应做出相应改变。 -s参数其实是-T trunk -b branches -t tags的缩写，这些参数告诉git这些文件夹与git分支、tag、master的对应关系。 2.--prefix=svn/ 给svn的所有remote名称增加了一个前缀svn，这样比较统一，而且可以防止warning: refname 'xxx' is ambiguous.
看下用git-svn克隆的项目情况（运行git branch -a），此处git的分支情况是与svn文件夹对应的。 简单来说就是，首次新建分支会记录和svn远程对应分支的追踪关系，之后你的所有commit都是在本地的；并且和纯git管理的项目没有区别，只是在git svn rebase和git svn dcommit的时候才会和svn仓库发生关系
一般工作流程（推荐） 新建分支git checkout -b <本地分支名称> <远程分支名称> 示例：git checkout -b a svn/a
说明：此处新建了一个本地分支a，与svn的a分支对应。 在本地工作，commit到对应分支上
git svn rebase 从svn上更新代码, 相当于svn的update。
git svn dcommit 提交你的commit到svn远程仓库，建议提交前都先运行下git svn rebase。 在git本地其他分支工作的情况
git chechout -b a svn/a 此处新建了一个本地分支a，与svn的a分支对应。 git checkout -b feature1 在a分支的基础上，开一个本地feture1分支 在feture1分支进行开发，有了多次commit 在feture1分支上进行git svn rebase 和 git svn dcommit，这样feature1的commit也会提交到svn的a分支上。 需要注意的是要记住feture1是从哪个分支checkout的，它的svn远程分支就与哪个相同。比如此处是a分支，那么svn分支就是svn/a，commit就会提交到svn的a分支。 使用git-svn处理代码冲突的步骤有些繁琐，不过瑕不掩瑜吧。这里用一个小例子来说明一下。
假设某svn中心库上的某个项目foo中只有一个源码文件foo.c：
- 我在使用git-svn clone检出版本时，foo.c当时只有一个commit版本信息："svn v1"；
- clone出来后，我在本地git库中修改foo.c，并通过git commit提交到本地git库中，版本为"git v1"；
- 不过与此同时另外一个同事也在修改foo.c这个文件，并已经将他的修改提交到了svn库中，版本为"svn v2"；
- 此时我使用git-svn dcommit尝试提交我的改动，git-svn提示我： Committing to svn://10.10.1.1:80/foo ... M foo.c 事务过时: 过期: ”foo/foo.c“在事务“260-1” at /usr/lib/git-core/git-svn line 570
- 使用git-svn rebase获取svn服务器上的最新foo.c，导致与foo.c冲突，不过此时svn版本信息已经添加到本地git库中(通过git log可以查看)，git-svn rebase提示你在解决foo.c的冲突后，运行git rebase --continue完成rebase操作；
- 打开foo.c，修改代码，解决冲突；
- 执行git rebase --continue，git提示我： You must edit all merge conflicts and then mark them as resolved using git add
- 执行git add foo.c，告知git已完成冲突解决；
- 再次执行git rebase --continue，提示"Applying: git v1"，此时"git v1"版本又一次成功加入本地版本库，你可通过git log查看；
- 执行git-svn dcommit将foo.c的改动同步到svn中心库，到此算是完成一次冲突解决。