SVN迁移至Git：历史迁移量及Git历史容量咨询

我处理过不少大型SVN到Git的迁移项目，结合实际经验来给你解答这两个问题：

一、SVN可迁移的历史规模：没有硬限制，但要考虑实际可行性 #

从技术上来说，SVN的历史不管是按年限（10年、15年甚至更久）还是存储大小（几十GB），都可以迁移到Git——只要你用对工具（比如git-svn、svn2git这类成熟的迁移工具）。但实际操作中，你需要重点关注这几个点：

• 历史清理是关键：如果你的SVN仓库里堆满了废弃分支、冗余标签、大体积二进制文件（比如旧安装包、日志、临时资源），直接迁移会导致Git仓库臃肿不堪。我曾帮客户迁移过一个12年历史、45GB的SVN仓库，清理掉无用分支/标签和历史中的大文件后，Git仓库最终只有8GB左右，日常操作完全流畅；如果不清理，迁移后的仓库可能超过30GB，克隆一次就要几十分钟。
• 工具的处理效率：git-svn对于超大规模的提交历史（比如10万+次提交）可能会出现速度慢、中途崩溃的情况，这时候可以换用svn2git，或者采用分阶段迁移：先迁移最近3-5年的核心历史，再按需导入更早的归档历史，甚至只保留最近的活跃历史，把古老历史留在SVN中归档。
• 团队需求优先：如果团队几乎不会查阅5年前的历史，完全可以考虑截断历史，只迁移最近的有效提交——这样能大幅降低迁移复杂度和仓库体积。

二、Git的历史存储容量上限：无硬性限制，但受性能和托管环境约束 #

Git本身没有官方的存储容量上限，它的分布式设计理论上支持任意大小的仓库，但实际使用中有这些实践限制：

• 本地操作性能门槛：当Git仓库体积超过10GB后，克隆、拉取、分支切换、提交等操作会明显变慢；如果超过50GB，日常开发基本会变得卡顿，除非你用Git LFS（大文件存储）把二进制文件从Git仓库中剥离出去。
• 远程托管平台的限制：比如GitHub的免费仓库对单个LFS文件有10GB的限制，总仓库大小虽无严格上限，但如果过大可能会收到平台的提醒甚至限制；GitLab的托管仓库也有存储配额，自我管理的GitLab实例可以自行调整上限，但同样要考虑服务器的存储压力。

三、迁移前的实用建议 #

• 先对SVN仓库做一次彻底的历史清理：用svnadmin dump导出仓库后过滤掉无用内容，或者用工具移除历史中的大文件（比如SVN的svn filter命令）。
• 评估团队对历史的需求：如果古老历史使用率极低，果断截断，只迁移活跃历史。
• 强制使用Git LFS管理二进制文件：这是避免Git仓库臃肿的核心手段，尤其是有大量图片、安装包、设计稿的项目。
• 先做测试迁移：克隆测试后的Git仓库，验证提交历史、分支、标签是否完整，测试日常操作的流畅度，没问题再正式迁移。

内容的提问来源于stack exchange，提问作者Nadza