如果你在读这篇文章，说明你跟大多数开发者一样对GIT感兴趣，如果你还没有机会来试一试GIT，我想现在你就要了解它了。
GIT不仅仅是个版本控制系统，它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN背景的人，你需要做一定的思想转换，来适应GIT提供的一些概念和特征。所以，这篇文章的主要目的就是通过介绍GIT能做什么、它和SVN在深层次上究竟有什么不同来帮助你认识它。
那好，这就开始吧…
1.GIT是分布式的，SVN不是：
这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。
GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提 交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。
同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。
有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。
2.GIT把内容按元数据方式存储，而SVN是按文件：
所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的 体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分 支，版本记录等。
3.GIT分支和SVN的分支不同：
分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn
propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。
然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。
4.GIT没有一个全局的版本号，而SVN有：
目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代 码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线 索，请在评论里奉献出来与大家共享。
更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。
5.GIT的内容完整性要优于SVN：
GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论
–http://stackoverflow.com/questions/964331/git-file-integrity
GIT和SVN之间只有这五处不同吗？当然不是。我想这5个只是“最基本的”和“最吸引人”的，我只想到这5点。如果你发现有比这5点更有趣的，请共享出来，欢迎。
=========================================================================================
下面我结合自身体会，逐条评论一下：
1.GIT是分布式的，SVN不是：
这一点绝对是最最关键的重点，与原作者不同，我要特别强调的是这一点对身处大陆的码农们的重要性。为什么？因为人家老外下全套android源码要几个小时，而我们要十几二十个小时，甚至好几天，还会不停断线！
分布式的最大好处，在于当你要切换不同的提交，不同的分支时，不再需要联网。试想一下，要是google的android源码用svn（这个是纯假设，实际上是完全不可行的，后面会提到），本来在大陆下一次代码就够慢的了，要是每天再切个几次分支和提交，那就别活了。所以在这一点上，我不说git完爆svn，应该说是分布式完爆非分布式。
2. GIT把内容按元数据方式存储，而SVN是按文件：
说实话，我没看出来原文列第二点出来是为了说明什么。这确实是个区别，但一般用户是不需要了解的。
看到评论中有人提到了提交冲突的问题。真发生了大规模冲突，不管git还是svn，都是挺让人感到头疼的，两者对冲突的解决办法也是差不多的。个人见解，冲突是靠良好的团队管理和项目分工来尽力避免的，但真发生了，解决起来都差不多，也没见哪个版本控制系统是以解决冲突效率高作为卖点的。当然不存在冲突的版本管理系统也有，VSS嘛，往前推个10年，中兴全公司都在用呢，呵呵~
3. GIT分支和SVN的分支不同：
分支确实是一个重点，只不过原文没说到点子上，不过看文章是挺久之前的，可能那时候git还没现在这么普及（当然现在国内也未必有多普及），也情有可原吧。
这里我就说最关键的一点，你可以看完整的android代码，如果没有，可以用git
clone个linux的完整代码库，然后用git
branch -r命令看看，你会发现有几十个甚至近百个分支，如果你只用svn的话，你一定完全无法想象。但这就是git分支的优势，因为git是基于差异来管理分支的，其分支的代价极小，再结合第一点，所以其切换分支也极为方便和快捷。这一点上我认为git是优于svn的，之所以我不说完爆，是因为这一点要结合项目需求，你的项目不是android，不是linux，没有大量分支并行开发、合并的需求，其实用svn也是可以的。但用git，你可以为一个单独的小功能拉分支，为一轮完整的测试拉分支，为你的每一个客户单独拉分支，等等等等，基本上是想拉就拉，这一点svn应该是比不上的。
至于原文提到的合没合并的问题，svn我不常用，git下用git
log命令，加上--graph参数，再配合--oneline和--color，我觉得是很方便直观的。
4. GIT没有一个全局的版本号，而SVN有：
原文承认这一点不如svn，我也承认，但要补充说明一下，git每次提交产生的40位（160bit）哈希值，是完全可以等同于svn全局id的作用的，之所以说不如，只是因为不好记而已。
5. GIT的内容完整性要优于SVN：
完整性这一点git要优于svn这是事实，虽然我个人不论git还是svn，都没碰到过这类问题。
反正对于git，每个克隆都是个完整的库，只要有一个克隆在，服务器被雷劈了都不怕，有点狡兔三窟的味道。当然，我这里说的跟原文说的已经不是一回事了。
看到有评论说git鼓励人们拉分支，这完全就是本末倒置了。事实是，git在分支这一点上优势巨大，所以当项目有大量分支的需求时，自然git就脱颖而出了。这也是为什么android、linux用不了svn的原因。至于说svn的commit是一种主动责任，稍微用点脑子想想，可能存在一个版本控制系统，不需要程序员承担所谓的主动责任么？无非在VSS里面，是checkout/checkin，在svn里面是commit，git又把svn的commit拆分成了commit和push两步而已。该评论实在是过于主观，误导倾向太重。
最后说说git的不足，结合项目经历，个人认为最大的是两点，第一，图形界面支持差，git本身是纯命令行的，图形化的界面也从来不是git的开发目标之一，所以虽然有第三方开发了图形界面支持，但这始终是git的短板；第二，git本身是不支持基于目录的鉴权认证的，我有碰到过几个boss挺在意这个的，虽然也有插件能解决这个问题，但我没用过。git是linux之父专门为了linux内核源码而开发设计的，人家不在意这两点，也完全可以理解。
选择版本控制工具，要结合各方面的因素，我反正也见过一群中兴出来开公司的老古董，到今天都还在坚持vss的。我只能说git是我用下来感觉最方便，功能最强大的（本人开发环境是纯linux，写代码看代码用vim，工作内容有涉及跨平台，但vs之类的ide环境仅仅用来编译一下而已）。如果你的项目很“linux”的话，那我实在找不到不用git的理由。你只要想一想，天才如Linus者，会搞出个不如svn的东西来跟自己过不去么？