git 到 svn 双向同步的实现

[gouchaoer2]

这算是一个比较常见的场景，比如：不同的团队直接合作通过 svn 管理代码，但是团队内部用确是 git ；或者历史遗留项目已经在 svn 上了不能动，但是团队想使用 git。注意这里 svn 或者 git 并不是彼此的一个 mirror，而是需要双向同步。

作为半个 devops 我接到这个场景前前后后花了 3 周的时间吧，在 stackoverflow 上有这个问题的讨论：https://stackoverflow.com/questions/907913，里面有 3 个可以参考的解决方案。由于我这边的基础设施有自己的限制，经过研究之后发现现成的 3 个方案都不满足，所以最终决定自己手撸一个 git 到 svn 的双向同步方案。

具体实现如下：

本地的 git 仓库是通过自建 gitlab 托管的（已经包含了 docker registry ），然后搭建了 jenkins。同步逻辑本身就是一个 gitlab 上的项目，该项目一更新就触发 jenkins 任务，在 jenkins 任务中根据写好的 Jenkinsfile 来 build 好一个 docker 镜像，然后上传到 docker registry 中供别人使用。现在同事 A 要把 gitlab 上的仓库 repo1 和远程的 svn 仓库进行一个双向同步，那么他只需要按照模版新建一个 Jenkins 任务，在 jenkins 任务里面通过启动预先 build 好的同步逻辑的 docker 镜像，同步挂载当前工作目录（也就是 jenkins 刚从 gitlab 同步下来的 git 仓库目录）到 docker 容器内部，然后在镜像中完成 git 到 svn 的双向同步逻辑。读到这里你可能觉得还是挺简单的，但是有个限制条件是 svn 是不能在本地 Jenkins 中直接访问的，必须通过远程开发机才能访问，这就让问题的复杂度直线上升了

怎么办呢？只有在同步逻辑中先通过 ssh 连上远程开发机，远程执行手动双向同步的逻辑咯，这里面涉及到非常繁琐的内容处理，一整套撸下来我对 shell、git、svn、jenkins 和 docker 的认识都上了一个层次。

执行同步逻辑的时候分两步走：

1、svn 到 gitlab 的同步：通过在同步逻辑中通过 sshpass 连上开发服务器，进入 checkout 出来的 svn 代码目录，然后在该目录下创建一个新的 git 仓库（注意这里用的 git init 没有--bare ），把 git 和 svn 彼此忽略'.git'和'.svn'的设置弄好。执行 svn 更新，手动的去解析 svn 的历史 log，得到一份需要转换到 git 的历史 svn 的 revision 列表，然后根据这份列表从头开始 svn update -r REVISION_NO 这样把当前目录重置到 REVISION_NO 对应的快照，接着 git add -A && git commit 完成转换。然后 jenkins 中就 git fetch 来把开发服务器上的 git 更新拉下来，然后 merge 到本地分支的时候需要禁止冲突（如果冲突了以哪个代码仓库为准需要参考-Xthers/-Xours 这个 git merge 的选项），完了之后再 merge 到 gitlab 的远程分支，最后 push 到 gitlab 上。

2、gitlab 到 svn 的同步：这其实是一个反向的逻辑，我这里就列出一些别的细节。有时候一个 git 的 commit 可能对应一个空的 svn 的 revision，反过来也是如此，需要处理这种情况。在 merge 两个不同历史的分支时，参考 git 的-allow-unrelated-histories 选项。由于 svn 的分支实际上就是目录，而开发服务器上用来转化的 git 仓库也只用 master 分支。gitlab 上某个仓库有多分支需要同步到 svn 的不同子目录（分支）的时候，为了简化问题需要在开发服务器上 checkout 不同的 svn 子目录（分支），然后写多个 jenkins 任务来完成同步。为了记得上次同步了哪些 commit/revision，需要找个地方记住，这里我选了开发服务器上的.git 目录内部。svn 和 git 在 add、commit 和恢复快照的时候会遇到不同的特殊情况，为了处理这些特殊情况花了我很大的精力

如你所见，如果我在 jenkins 里面能直接访问 svn 仓库的话，我可以直接在 jenkins 里面 checkout svn 仓库，然后完成 git 到 svn 的双向同步。但是很遗憾只有远程开发机能连上 svn 仓库，而开发机我只有一个 ssh 权限，所以在 jenkins 里面通过 ssh 来远程完成转换，然后在通过 git over ssh 的方式完成 git 更新的上传和下载，这种操作是非常风骚的，需要强大的内容处理技巧。

最后关于冲突后数据丢失的问题，我是这么想的，由于 commit 到 gitlab 上的东西是丢不了的，所以 merge 的时候发生了冲突就以来自 svn 的更新为准。这样数据是丢不了，但是发生了冲突之后，一切同步都是照常进行的，没有任何提示。

业务逻辑我用的熟悉 php 写的，最后加起来 700 多行吧，加上别的 expect 脚本、Jenkinsfile、Dockerfile 啥的 1000 行以内搞定，没有依赖 git svn 插件完全手动转换。