Git是分布式、SVN是集中式，这是根本区别：Git本地含完整仓库（历史/分支/标签），可离线提交、秒级分支；SVN仅工作副本，依赖服务器，分支是目录拷贝、合并复杂，且无全局版本号。
git 和 svn 不是“换种写法”的同类工具，它们在底层设计上根本不同。选错版本控制系统，后期会持续付出隐性成本——比如分支卡顿、离线无法提交、权限配置绕弯、历史回溯变慢。
Git 是分布式，SVN 是集中式
这是最根本的分水岭，直接影响所有后续行为。
git clone 下来的目录里，.git 文件夹就是一个完整仓库：含全部提交历史、所有分支、全部标签、每一次 diff 的元数据。你断网也能 git log、git checkout、git commit、git branch。
svn checkout 得到的只是工作副本（Working Copy），.svn 里只存当前版本的元信息和少量缓存，没历史、没分支快照。断网后 svn status 还能用，但 svn log、svn merge、svn revert -r 全部失败——因为要连服务器查记录。
- 团队常踩的坑：误把 SVN 的“本地修改”当 Git 的“未提交变更”，结果
svn commit失败才发现网络不通，而 Git 此时早已git commit完成，就等联网git push - CI/CD 场景下，Git 可以在任意节点拉取完整历史做构建验证；SVN 构建机必须稳定连通中央库，否则
svn update直接中断流水线
Git 分支是轻量指针，SVN 分支是物理目录复制
git branch feature/login 本质只是在 .git/refs/heads/ 下写一行 40 位 SHA-1 哈希值，毫秒级完成。切换分支 git checkout feature/login 也只是重置工作区文件+移动 HEAD 指针。
svn copy ^/trunk ^/branches/v2.1 -m "create branch" 实际是在服务器端执行一次全量目录拷贝（哪怕只改一行），耗时随项目体积线性增长。大项目中，一次 svn copy 卡住几十秒很常见。
- SVN 分支合并需手动跟踪
svn:mergeinfo属性，漏合、重复合、方向反都是常态；Git 的git merge --no-ff或git rebase能清晰标记合并点与基础提交 - Git 支持
git worktree add ../my-fix-bug bugfix/issue-123开多个工作区共用一个本地仓库，SVN 没等效机制，想并行处理多个任务只能开多个 checkout 目录，磁盘和更新开销翻倍
Git 存快照，SVN 存差异
Git 每次 git commit 都对所有 tracked 文件生成 SHA-1 快照，相同内容只存一份（硬链接或 packfile 压缩），历史版本可独立校验完整性。git fsck 能立刻发现仓库损坏。
SVN 每次 svn commit 只存文件改动部分（delta），历史版本必须按顺序拼接才能还原——一旦中间某个 rev 损坏，后面所有版本都可能无法恢复。且二进制文件（如 PSD、ZIP）反复修改会导致仓库体积指数膨胀。
- Git 中
git blame查某行代码谁写的、何时改的，直接定位到原始提交；SVN 的svn blame在大仓库里可能超时或返回不完整结果 - Git 的
git filter-repo可安全删敏感文件历史；SVN 没原生等效命令，svnadmin dump+svndumpfilter操作极脆弱，稍有不慎整仓报废
Git 没全局版本号，SVN 有严格递增的 revision
SVN 的 r12345 是中央服务器上的唯一序号，所有人看到的“版本 12345”永远指向同一组文件状态。Git 的 commit hash（如 a1b2c3d）是本地计算出的 SHA-1，不同 clone 出来的仓库即使内容一致，其“最新提交”哈希也必然相同——但没有“第 N 次提交”这种跨仓库编号。
- SVN 的
svn log -r 1000:1010精确可控；Git 要靠git log --since="2026-04-01"或 tag/branch 名称来界定范围，时间或语义代替序号 - 某些遗留系统依赖 SVN 的 revision 做构建号或发布标识（如 “build-12345”），迁移到 Git 后得用
git describe --tags或git rev-list --count HEAD模拟，但要注意后者不保证线性（rebase 后计数会变）
git add 就直接 git commit；习惯“分支=目录”的人，会在 Git 里给每个小需求建远程分支，导致远端 origin 堆满废弃分支。这些不是操作问题，是模型理解没对齐。 
