分布式 vs 集中式
Git 和 SVN（Subversion）是两种最主流的版本控制系统，它们最根本的区别在于架构模型。
Git 是分布式版本控制系统。每个开发者的本地都有一份完整的版本库副本，包含所有的提交历史、分支和标签。即使中央服务器宕机，任何一个开发者都可以用自己本地的完整仓库恢复出一份新的中央仓库。
SVN 是集中式版本控制系统。所有的版本历史只存在于中央服务器上，开发者本地只有工作副本（即当前版本的文件），没有历史记录。如果服务器宕机且没有备份，所有历史版本信息将全部丢失。
这个架构差异直接决定了两者在以下维度的表现。
核心对比
| 维度 | Git | SVN |
|---|---|---|
| 架构 | 分布式，每台机器都有完整仓库 | 集中式，只有服务器有完整历史 |
| 离线工作 | 支持，所有操作在本地完成 | 不支持，大部分操作需要联网 |
| 服务器宕机影响 | 任何本地仓库都可以恢复 | 无备份则历史全部丢失 |
| 学习曲线 | 较陡峭，命令多且概念复杂 | 平缓，命令少且直观 |
| 分支管理 | 非常强大，创建/切换/合并秒级完成 | 分支是目录级别的拷贝，笨重且缓慢 |
| 代码合并 | 智能合并，冲突解决工具成熟 | 合并效率低，文件锁机制限制并发 |
| 权限控制 | 较弱，通过平台（GitLab/GitHub）补充 | 原生支持目录级别的细粒度权限 |
| 适合团队 | 技术团队 | 非技术团队（文档管理等） |
| 适合项目 | 中大型项目、高频协作 | 小型项目、文档版本管理 |
| 行业地位 | 绝对主流，新项目首选 | 遗留项目维护，特定行业使用 |
为什么 SVN 仍在使用
尽管 Git 已经成为事实标准，仍有一些团队在使用 SVN，主要原因包括：
历史包袱。很多传统企业（银行、电信、制造业）积累了大量 SVN 仓库，迁移成本和风险极高，索性继续维护。这不是技术选型问题，而是业务连续性的考量。
文档管理需求。SVN 对非技术人员非常友好——只需要学会 checkout、update、commit 三个操作就能完成文件版本管理。设计团队用 SVN 管理设计稿、产品团队用 SVN 管理需求文档，学习成本几乎为零。
目录级权限控制。SVN 原生支持对仓库中任意目录设置读写权限，这在某些有严格权限管控要求的场景中非常实用。Git 本身不支持这种细粒度的权限控制，需要依赖 GitLab 等平台来实现。
面试高频问题
在面试中遇到 "Git 和 SVN 的区别" 这类问题时，可以按以下思路回答：
- 架构差异：Git 是分布式，每个开发者本地有完整的版本库；SVN 是集中式，历史只存在于服务器。
- 离线能力：Git 支持完全离线工作；SVN 几乎所有操作都需要联网。
- 分支模型：Git 的分支是指针，创建和切换几乎不消耗资源；SVN 的分支是目录拷贝，操作笨重。
- 容灾能力：Git 天然具备容灾能力，任何副本都能恢复仓库；SVN 依赖服务器备份。
- 学习成本：Git 学习曲线陡峭但功能强大；SVN 简单易学但能力有限。
- 适用场景：Git 适合代码版本管理和团队协作开发；SVN 适合文档管理和非技术团队。
最佳实践建议
对于开发者：务必系统学习 Git，掌握常用命令和工作流。SVN 不需要专门学习，用到时再了解即可，它的学习曲线非常平滑，上手很快。
对于团队：新项目直接用 Git，选择 GitHub、GitLab 或 Gitea 作为托管平台。如果团队中有大量非技术人员需要文档版本管理，可以评估 GitLab 的 Web 界面是否能满足需求，通常不必为此单独维护一套 SVN。
↑