在软件开发领域，版本控制系统是维护代码健康、促进团队协作的关键工具。长期以来，Subversion（SVN）作为一种集中式版本控制系统，在许多组织中被广泛使用。然而，随着技术的演进和开发实践的改变，分布式的 Git 现在已经成为了许多开发者和团队的首选，但即便 Git 更适应现代开发的需求，仍有许多团队还在坚持使用 SVN。

那些还在坚持使用 SVN 的团队，是不想用 Git 吗？

Gitee 团队经过调研发现，在选择 SVN 而非 Git 的决策中，最重要的原因通常是对现有基础设施和流程的依赖。尽管 Git 提供了诸多先进特性，但他们可能觉得 SVN 完全满足他们的需求，迁移到 Git 看起来是一个不必要的风险和成本。

Gitee 团队为了降低这种风险和成本，让更多团队高效、完整地迁移至 Git，给还在使用 SVN 的团队提供了 SVN 代码库迁移方案。

该方案迁移效率高，迁移内容完整，适合多种类型的 SVN 历史仓库的迁移。针对 SVN 开发人员，Gitee 也将继续支持 SVN 对客户端及代码提交习惯，最大化的降低迁移的学习成本。

迁移的准备工作准备一台安装有最新 Git 环境的磁盘容量充足的电脑安装转换工具git-svn（https://gitee.com/mirrors/nirvdrum-svn2git）Git 仓库的远程地址及读写权限准备一份开发者的 SVN 用户名到 Git 全名+邮箱的映射关系列表文件 authors.txt，格式为：loginname = Username <user@example.com>`

由于 SVN 对每次提交只记录开发者的用户名，而 Git 存储其全名和邮件地址，这意味着需要对开发者信息进行映射转换，在准备authors.txt文件时，可以到团队系统数据库直接查询开发者登录名、用户名和邮件地址并拼接成指定的格式，或者可下载 Atlassian 的工具包 svn-migration-scripts.jar，通过命令拉取 SVN 仓库的用户并生成对应的开发者信息映射文件(需要 Java 运行环境支持) 。

java -jar svn-migration-scripts.jar authors https://svn.example.com > authors.txt转换仓库

准备工作完成后可以开始实施转移仓库了，需要注意的是，在转移 SVN 项目时要根据是否是标准的 SVN 文件布局来确定命令行的参数。

标准的 SVN 文件布局的仓库的迁移

如果 SVN 仓库使用标准的了/trunk、/branches和/tags的目录结构，就可在运行命令时加上参数--stdlayout。

该参数可将 SVN 仓库中的/trunk、/branches和/tags目录自动对应为 Git 仓库的master分支的目录、其他独立分支目录和仓库标签。

git svn clone --stdlayout --authors-file=authors.txt <svn-repo>/<project> <git-repo-name>如：git svn clone --stdlayout --authors-file=authors.txt https://svn.waterstrong.com/demo demo 非标准 SVN 文件布局的仓库的迁移

如果 SVN 仓库是非标准的目录布局，那就需要分别显示指定参数--trunk、--branches、--tags的路径。

git svn clone --trunk=/trunk --branches=/branches --branches=/bugfixes --tags=/tags --authors-file=authors.txt <svn-repo>/<project> <git-repo-name> Authors 文件的使用

–authors-file：前文提到需要使用参数--authors-file=<filename>读取开发者信息映射文件，文件内容格式为loginname = Username <user@example.com>，但如果在文件中不存在 SVN 某个用户名的对应关系，那么 git svn 操作会被自动中止。

因此，必须在authors.txt文件中添加丢失的用户对应关系后重新运行 git svn 命令。配置其 git config 时的 key 为svn.authorsfile即可。

–authors-prog：在使用authors.txt文件时，如果在某个 SVN 用户名对应关系不存在的情况下，命令也可以执行成功并自动使用默认值，可以使用参数--authors-prog=<filename>。配置其 git config 时的 key 为svn.authorsProg。

大仓库的转移策略

当 SVN 仓库非常大时，就需要消耗比较长的时间来完成转换。在这种情况下，可以选择放弃保存时间久远的提交历史记录以加速转换过程：

git svn clone -r${REVNUMBER}:HEAD --stdlayout --authors-file=authors.txt <svn-repo>/<project> <git-repo-name> 例如git svn clone -r19698:HEAD --stdlayout --authors-file=authors.txt https://svn.waterstrong.com/demo demo清理仓库

至此，SVN 到 Git 的转换工作已经接近尾声，如果只是关注trunk和master主分支，可以直接跳过进入下一部分内容；如果需要将分支和标签进行本地化，则需要进行清理仓库的操作。

对于 SVN 的分支和标签，转换操作不会将其导入到新的 Git 仓库中，而且在 Git 分支中也找不到 SVN 的分支branch以及对应的标签 tag，这时可以使用命令git branch -r可以查看到所有 SVN 的分支和标签，这是因为在使用git svn clone命令时会将 SVN 的分支和标签导入为 Git 的远程分支和标签，如下图所示：

可以使用svn-migration-scripts.jar快速实现对仓库分支和标签的清理工作：

java -Dfile.encoding=utf-8 -jar svn-migration-scripts.jar clean-git –force

将 SVN 分支和标签转换 Git 的本地分支和标签后结构如下图所示：

收尾工作

完成以上步骤后，迁移工作基本完成，仓库已经转换为了标准的 Git 仓库，可以执行 Git 命令关联远程仓库了：

git remote rm origin git remote add origin https://xxx.xxx/xxx/xxx.git git push origin [branch] 手动校验方案

大多场景下，需要我们分别计算对迁移后的 Git 仓库与迁移前的 SVN 仓库进行 SHA-1 值校验，以判断迁移过程是否顺利。

计算 Git 仓库 SHA-1 值find . -type f -not -path "./\.git/*" \( -exec sha1sum {} \; \) | sha1sum

这条命令用于计算 Git 仓库中除了.git目录外所有文件的 SHA-1 值，并最终生成一个综合的 SHA-1 值。

计算 SVN 仓库 SHA-1 值find . -type f -not -path "./\.svn/*" \( -exec sha1sum {} \; \) | sha1sum

和 Git 仓库相同，SVN 仓库同样排除了记录版本信息的目录。

最后，根据两条命令的输出结果进行比对，如果 SHA-1 值一致则表明迁移成功。在部分情况下，会出现因为换行符导致验证不一致，可通过更改本地 Git 配置解决：

git config --global core.autocrlf false

当该配置改为false时，不会进行换行符的转化，随后重新执行迁移，再次进行校验即可。

校验完成后，迁移的工作就算圆满完成了。尽管从 SVN 迁移到 Git 可能涉及学习新工具和改变现有工作流程，但长期来看，Git 提供的效率提升、灵活性和社区支持使得这一转变非常有价值。

对于希望提升软件开发效率、加强团队协作并保持与行业发展同步的开发者和组织来说，Git 都提供了一个更强大、更灵活、更安全的版本控制环境，而 Gitee 也在此基础上为研发团队提供了一站式研发平台，覆盖研发链路所有环节，将研发流程流程化、自动化、数据化。

点击链接：https://gitee.com/enterprises ，开始使用 Gitee 企业版，帮助你的企业迅速完成数字化转型，定义自己的敏捷协作方式。