GIT是分布式的，SVN不是
这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。
因为每一个开发人员的电脑上都有一个Local Repository,所以即使没有网络也一样可以Commit，查看历史版本记录，创建项 目分支等操作，等网络再次连接上Push到Server端。
GIT把内容按元数据方式存储，而SVN是按文件
因为,.GIT目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。.GIT目录的体积大小跟.SVN比较，你会发现它们差距很大。
GIT版本号是全球唯一的，而SVN版本号是全局唯一的
GIT对于每一次提交，通过对文件的内容或目录的结构计算出一个SHA-1 哈希值，得到一个40位的十六进制字符串，GIT将此字符串作为版本号。SVN与GIT版本号比较
所有保存在
GIT数据库中的数据都是用此40位的哈希值作索引的，而不是靠文件名。使用哈希值作版本号的好处就是对于一个分布式的版本控制系统，每个人每次提交后形成的版本号都不会出现重复。另一好处是保证数据的完整性，因为哈希值是根据内容或目录结构计算出来的，所以我们还可以据此来判断数据内容是否被篡改。
SVN的版本号是连续的，可以预判下一个版本号，而GIT的版本号则不是。
因为 subversion 是集中式版本控制，很容易实现版本号的连续性。GIT是分布式的版本控制系统，而且GIT采用 40 位长的哈希值作为版本号，每个人的提交都是各自独立完成的，没有先后之分（即使提交有先后之分，也由于PUSH/PULL的方向和时机而不同）。GIT的版本号虽然不连续，但是是有线索的，即每一个版本都有对应的父版本（一个或者两个），进而可以形成一个复杂的提交链GIT的版本号简化：GIT可以使用从左面开始任意长度的字串作为简化版本号，只要该简化的版本号不产生歧义。一般采用7位的短版本号（只要不会出现重复的，你也可以使用更短的版本号）。
在使用中，发现，每次对整个目录进行提交，SVN是把所有文件无论有无更新都打上版本号，而GIT则只是对更新文件进行打版本号，一开始我觉得SVN的这种做法没有GIT合理，没有更新过的文件打版本号一种浪费，但结合SVN本身的特点，SVN的每个版本都是完整的仓库，按某大神说法，这样容错率高(保留疑问)
GIT 分支和SVN的分支不同
分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。所以，经常会发生有些分支被遗漏的情况。
然而，处理GIT 的分支却是相当的简单和有趣，你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。因为git是基于差异来管理分支的，其分支的代价极小
我在实际操作中只体验过git的分支操作，用命令行确实方便切换而且很容易有提示知道未被合并的分支
SVN必须先Update才能Commit
忘记了合并时就会出现一些错误，git还是比较少的出现这种情况。
实际使用中，git比较友好的一点是，有冲突会提示解决冲突，SVN则是直接update，然后出现一堆冲突
SVN的安全控制和权限管理更好。
git 下，如果一个人clone以后，所有代码和历史都泄漏了。而 SVN 有细致的按照目录级的权限控制
GUI工具，还是 SVN 更强
clone新仓库的区别
克隆一份全新的目录以同样拥有五个分支来说，SVN是同时复製5个版本的文件,也就是说重复五次同样的动作。而git只是获取文件的每个版本的 元素，然后只载入主要的分支(master)，这就决定了git的速度比SVN 快
git的内容完整性要优于SVN ：
git的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
处理冲突的区别
git的冲突会提示你先解决冲突再提交，我自己解决冲突的一般做法是先把本地改动用git stash保存起来，把服务器上的改动pull下来，再git stash pop，出现冲突手动解决冲突再提交，而SVN则不会提示冲突，当你知道有冲突时，本地已经是冲突文件了，SVN会用感叹号标识冲突文件和文件夹，本地会出现三个文件
其中：.mine是你自己修改后准备提交的那个版本；.r3368是你们的初始版本；.r3439是别人赶在你之前提交的那个版本
找到冲突的文件右键找到Edit conflicts 对冲突进行修整，调整好之后保存，右键选择Resolved...便可解决冲突
