GIT版本控制 — GIT与SVN的相互转换 (三)
git-svn
git-svn用于Git和SVN的转换，可以把Git仓库迁移成SVN仓库，反之亦可。
详细介绍可见[1]，或者命令行输入git-svn。
Bidirectional operation between a Subversion repository and git.
git svn can track a standard Subversion repository, following the common "trunk/branches/tags" layout,
with the --stdlayout option. It can also follow branches and tags in any layout with the -T/ -t/ -b options.
Once tracking a Subversion repository, the git repository can be updated from Subversion by thefetch
command and Subversion updated from git by the dcommit command.
Git迁移到SVN
把Git迁移到SVN？没错，还真有这种需求，虽然较少：）
Git has a feature to work with SVN repositories, git-svn, but that's intended to check out
existing code from SVN and work on it, not publishing an existing Git tree into a SVN repository.
(1) 依赖包
需要安装subversion-perl、perl-TermReadKey。
Git中带有git-svn，需要确定它的路径可在PATH中找到。
(2) 建立svn项目
在svn服务器中新建svn项目proj。
# svnadmin create proj
(3) svn项目的本地初次提交
# svn mkdir http://IP:PORT/svn/proj/trunk \
http://IP:PORT/svn/proj/branches \
http://IP:POPT/svn/proj/tags \
http://IP:PORT/svn/proj/docs -m "Initial import"
(4) 提交Git proj项目到SVN proj
进入Git proj项目。
# git-svn init -s http://IP:PORT/svn/proj // -s表示svn为标准布局
标准布局的意思就是：
trunk分支为：proj/trunk，可以用-T另外指定
branches分支为：proj/branches，可用-b另外指定
tags分支为：proj/tags，可用-t另外指定
# git-svn fetch // 获取SVN proj的更新
r1 = 79563196f21ce4699a04fa4ae24d0ca916bf3acf (refs/remotes/trunk)
trunk分支代表SVN proj的trunk分支
# git-svn dcommit // 提交Git proj的更新
注意！这个时候会报错：
Unable to determine upstream SVN information from HEAD history.
Perhaps the repository is empty. at /usr/local/git/libexec/git-core/git-svn line 852.
因为现在Git proj的commits不知道要放到SVN proj的哪个版本之后，即Git proj的这些提交要
放在SVN哪个版本之后（显然是放到SVN的初始提交之后，但是Git proj就是不知道，因为设计者
并不考虑把Git proj转为SVN proj的情况：）
以下是详细描述：
This fails since the git svn command can't figure out which commits to push: there's no link
between our original Git repository and the Subversion heads.
To fix this, we can use a Git graft to link them. We'll tell Git the commit which created the SVN
folder in which we want to store the project is the parent commit of the first commit in our Git
repository.
解决方法
# git show-ref trunk // 显示SVN proj trunk分支的HEAD，即r1
79563196f21ce4699a04fa4ae24d0ca916bf3acf refs/remotes/trunk
# git log --pretty=oneline master | tail -n 1 // 显示Git proj 的第一个commit
561c439a15f807b8d62551a0c64f939c15489899 initial import
# echo "561c439a15f807b8d62551a0c64f939c15489899 79563196f21ce4699a04fa4ae24d0ca916bf3acf" >> .git/info/grafts
把Git proj从561c43开始的提交，添加到SVN proj在795631之后的提交。
# git-svn dcommit // 提交Git proj的更新到SVN proj中
这个时候就把Git proj完整的转化成SVN proj，后者完全符合SVN的规范了。
(5) 把git分支提交到svn的分支
如果原来的git仓库不仅有master，还有其它分支，那么怎么把git的分支提交为svn的分支呢？
这个时候就要用到git rebase了。
过程如下：
在远端svn仓库中创建一个新分支。
# svn cp URL/trunk URL/branches/remote-branch
更新本端Git仓库。
# git-svn fetch
切换到本端的分支。
# git checkout local-branch
创建一个用于临时用的分支，其实和local-branch是一样的。
# git checkout -b temp-local-branch
关键点来了，把本端分支的所有修改，合并到远端分支。
# git rebase remotes/remote-branch
完成上一步以后，远端分支已经含有本端分支的所有commit。
接着可以把修改提交到svn仓库了。
# git svn dcommit
最后把本端的临时分支删除。
# git branch -D temp-local-branch
此时再查看svn仓库，就会发现branch/remote-branch已经是原来的git分支了。
不过svn分支的日志顺序，相较于原来git分支的可能会有所不同，这是由rebase引起的，正常现象。
(6) 从git分支更新svn分支
修改.git/config，添加远程分支：
[svn-remote "branch"]
url = URL/proj/branches/branch
fetch = :refs/remotes/branch
绑定本地分支和远程分支：
[branch "local-branch"]
remote = .
merge = refs/remotes/branch
修改了本地分支local-branch后，可以直接提交到远端svn的branch分支了。
# git-svn dcommit
SVN迁移到Git
相比之前介绍的Git迁移到SVN，SVN迁移到Git才是主流趋势，也更加容易，因为这是git-svn的主要目的。
同样用git-svn来完成迁移：
git-svn primarily can be used to checkout a Subversion repository to a local Git repo and then
push your changes back to the original Subversion repository.
克隆SVN仓库，可以使用-T trunk、-b branches、-t tags来指定对应分支，-s表示采用标准布局。
# git-svn clone -s URL/proj proj
相当于执行了git-svn init和git-svn fetch。
把SVN仓库的更新同步到Git。
# git-svn rebase
创建.gitignore文件。
# git-svn create-ignore
将Git的更新提交到SVN仓库。
# git-svn dcommit
Author
zhangskd @ csdn blog
Reference
[1]. https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
[2]. http://plpatterns.com/post/234334879/how-to-convert-a-local-branch-in-git-to-a-remote
[3]. http://www.cnblogs.com/kym/archive/2010/08/12/1797937.html