SVN 和 GIT/Perforce 的核心区别

不同文件修改的处理

SVN 的自动合并这些修改

• 不同人修改不同文件，不会有任何提示，对于工作以文件划分职责的人表示很 OK，也是策划配表文件要求写一个“合并”工具的源头。

• 对于一个项目中，不同文件的内容有互相关联的功能来说，可能导致第三方错误。导致“在我机器上很好啊？”问题频繁发生。

GIT/Perforce 的需要开发者先更新再提交

• 不管改了什么，都提示开发者处理，当“网盘”使用的人表示很烦

• 因为都经过开发者合并，所以可以自动做一些单元测试等验证工作，减少问题

对于分支的使用方法

SVN 的分支是目录

• 优势：分支就是目录，非常直观，不需理解，当“网盘”用即可

• 问题：

￮同时拥有多个分支，需要下载多个目录很占硬盘

￮如果使用一个目录，切分支时要联网，可能很慢

￮习惯不切分支，而是在多个分支目录上直接改文件的用户，天长日久之后，已经合并不回去了

GIT/Perforce 的分支不是目录

• GIT/Perforce 的问题：分支看不见，不直观；要用专门的软件如 SourceTree 才能看见

• GIT/Perforce 的优势：切换分支快

权限管理

SVN/Perforce 的权限

权限可以细分到项目里的目录

GIT 的权限

这个特性 GIT 完败，一个项目只能使用同一套权限，如果有大量的项目互相依赖，要拉代码需要申请几十个权限（因此诞生了字节内部的“一键批量申请权限”的工具）。这也是 Google 嫌弃 GIT 的主要原因。

其他差别

• 非 git 无法提供无网络的快照、回滚能力，对于离线开发，譬如在飞机上写代码不友好（听起来并没什么用?）

• .svn/ 目录到处都是，.git/ 只有一个。但是，太多 .svn/ 在代码搜索等操作上，造成很多麻烦，一搜一大堆同名函数在 SVN 内部文件里。

总结

• 对于工作互相隔离、非文本类（源代码）文件开发的用户，SVN 非常直观，基本当作网盘使用即可（svn update 等于下载文件；svn commit 等于上传文件；开分支就是拷贝个目录，合并是不存在的），无学习成本。但是对于共同开发源码的程序员来说，这种模拟成目录的设计，会导致很多误用，从而产生问题。

• 对于代码开发人员，自动合并是一个核心问题，使用 SVN 具有其固有缺陷。