从SVN到Git的平滑迁移：完整指南与实战步骤
目录导读
迁移前的关键准备工作
在开始将项目从SVN迁移到Git之前,充分的准备工作能确保迁移过程顺利无误，首先需要收集SVN仓库的关键信息，包括仓库结构、分支策略和用户映射。
信息收集阶段：
使用 svn log -q 命令分析SVN仓库的历史记录，了解提交频率和贡献者信息，特别要注意SVN的目录结构——标准的SVN仓库通常包含trunk（主干）、branches（分支）和tags（标签）三个主要目录，但有些项目可能使用非标准结构，记录这些信息对后续的映射至关重要。
用户映射文件创建：
由于SVN和Git的作者信息格式不同，需要创建用户映射文件，通过运行 svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2"@"ww.jxysys.com">"}' | sort -u 可以提取SVN中的所有用户名，然后手动或半自动地将其转换为Git格式（姓名<邮箱>）。
工具与环境准备： 确保系统已安装最新版本的Git和git-svn工具，对于Windows用户，推荐使用Git Bash；Linux和macOS用户可通过包管理器安装，确保有足够的磁盘空间存放SVN仓库的完整历史记录，特别是对于大型仓库，这个过程可能需要大量空间。
使用git-svn克隆SVN仓库
git-svn是Git官方提供的与SVN桥接的工具，能够将SVN仓库完整地克隆到本地Git仓库中，包括所有的历史记录。
基础克隆命令：
对于标准布局的SVN仓库，使用命令 git svn clone <SVN仓库URL> --authors-file=users.txt --stdlayout，其中--authors-file参数指定上一步创建的用户映射文件，--stdlayout参数告诉git-svn仓库遵循trunk/branches/tags标准结构。
非标准结构处理：
如果SVN仓库使用非标准目录结构，需要明确指定路径映射。git svn clone <SVN仓库URL> --authors-file=users.txt --trunk=main --branches=branches/* --tags=tags/*，在某些情况下，如果分支和标签分散在不同位置，可能需要多次指定--branches和--tags参数。
克隆过程优化：
对于大型仓库，克隆过程可能耗时很长，可以添加--no-metadata选项来避免在Git提交消息中添加git-svn特定元数据，使仓库更干净，如果不需要完整历史，可以使用-r参数指定只迁移部分修订版本，如-r HEAD:1000表示只迁移最近的1000个修订版。
转换SVN分支与标签为Git格式
SVN的分支和标签本质上是目录拷贝,而Git中的分支和标签是轻量级的指针，迁移后需要将SVN的这些结构转换为Git原生支持的形式。
分支转换处理：
git-svn克隆后，SVN分支会作为远程引用存在（如refs/remotes/origin/*），需要将这些远程分支转换为本地Git分支，一个高效的方法是使用命令 for branch in $(git branch -r | grep -v tags | grep -v trunk); do git branch ${branch#origin/} $branch; done，这会遍历所有远程分支（排除标签和主干）并创建对应的本地分支。
标签转换技巧：
SVN标签在Git中也会被创建为远程引用，由于标签应该是静态的，我们需要将其转换为Git的轻量标签或注解标签，使用以下脚本：for tag in $(git branch -r | grep tags); do git tag -a ${tag#origin/tags/} -m "从SVN迁移的标签" $tag; done，这将为每个SVN标签创建带注解的Git标签，保留标签信息。
处理特殊分支情况： 有些SVN仓库可能包含非标准命名的分支或含有特殊字符的分支，这些需要手动处理，可以先将它们克隆为Git分支，然后根据需要重命名，检查是否有分支是从非标准路径创建的，确保所有分支都被正确迁移。
迁移后的整理与远程仓库同步
完成基础迁移后,需要对Git仓库进行整理，然后推送到远程Git服务器，使团队能够开始使用Git工作流程。
清理git-svn元数据：
如果克隆时没有使用--no-metadata选项，Git提交中会包含git-svn-id元数据，可以使用 git filter-branch --msg-filter 'sed "/^git-svn-id:/d"' -- --all 命令移除这些信息，使提交历史更干净，但请注意，这会重写历史，适用于在迁移后尚未开始协作的情况。
推送到远程Git仓库：
在ww.jxysys.com或其他Git托管服务上创建新仓库后，将本地仓库添加为远程源：git remote add origin <Git仓库URL>，然后使用 git push origin --all 推送所有分支，使用 git push origin --tags 推送所有标签，对于大型仓库，可以考虑分批次推送或使用--mirror参数进行镜像推送。
团队协作切换： 通知团队成员迁移时间表，确保在迁移期间没有新的SVN提交，迁移完成后，更新所有文档中的仓库地址，将构建和部署系统配置指向新的Git仓库，建议保留SVN仓库一段时间为只读状态，以备不时之需。
常见问题与解决方案
Q1: 迁移后如何验证历史记录的完整性？
A: 使用git log --oneline --graph --all可视化查看提交历史，检查分支合并情况，比较SVN和Git的关键提交数量，使用git svn info获取的SVN版本号应与Git中最后一个包含git-svn-id的提交信息匹配，还可以验证特定文件的完整历史记录。
Q2: 如何处理SVN外部引用(svn:externals)？
A: git-svn不会自动转换外部引用，对于简单的外部引用，可以将其转换为Git子模块，首先将外部引用的仓库单独迁移到Git，然后在主仓库中使用git submodule add添加，对于复杂的外部引用结构，可能需要重新考虑项目依赖管理方式。
Q3: 大仓库迁移过程中出现内存不足怎么办？
A: 可以尝试分段克隆：先克隆最近的修订版git svn clone -r HEAD:1000，然后逐步获取更早的历史git svn fetch -r 999:1，调整git-svn的缓存大小：git config svn.cachesize 1000（减少缓存），或者考虑在性能更强的机器上进行迁移。
Q4: 迁移后如何处理SVN的忽略列表(svn:ignore)？
A: git-svn会自动将svn:ignore属性转换为.gitignore文件，迁移后检查根目录和子目录中的.gitignore文件是否完整，由于SVN和Git的忽略模式语法略有不同，可能需要手动调整一些模式，使用git check-ignore命令测试忽略规则效果。
成功从SVN迁移到Git不仅能获得Git强大的分支功能和离线操作能力,还能提高团队开发效率，迁移过程中耐心和细致是关键，务必在正式切换前进行全面测试，如果在迁移过程中遇到特殊问题，可以访问ww.jxysys.com获取更多高级技巧和社区支持。