Git 的优势主要有：

　　1、更方便的 Merge

　　分布式管理必然导致大量的 Branch 和 Merge 操作。因此分布式版本控制系统都特别注意这方面。在传统的 CVS 里面制作 Branch 和 Merge 简直就是噩梦，Subversion 作为一个用于替代 CVS 的系统，专门改进了 Branch 操作。然而似乎人们没有注意到，Branch 是轻松了，可是 Merge 呢？如果不能很方便地 Merge 回来，做 Branch 仍然是噩梦。

　　事实上，我就经历过在开发团队里面由于队友操作不对而在 Merge 的时候把我的许多代码都覆盖掉了。当时正是使用的 subversion 。虽然源代码仍然在历史里面，但是要去一个一个地找出被覆盖掉的文件并恢复过来确实是一件很难忘的事情。

　　2、更方便的管理

　　传统的版本控制系统使用*仓库，一些仓库相关的管理就只能在仓库上进行。赋予开发团队每一个人*仓库的管理权限是非常不好的。但是有时候确实会比较不方便的地方。

　　3、更健壮的系统

　　分布式系统一般情况下总是比单服务端的系统要健壮，因为当服务端一旦挂掉了整个系统就不能运行了。然而分布式系统通常不会因为一两个节点而受到影响。

　　4、对网络的依赖性更低

　　虽然现在网络非常普及，但是并不是随时随地都有高速网络，甚至有时候根本没有网络可以访问。低速的网络会让人心情烦躁，有时候就呆呆地盯着屏幕上的 commit 进度，什么事情也干不了。而没有网络连接更是致命的：你无法 commit ！这表示你进行任何改动以前都必须小心翼翼，否则你可能再也找不会你曾经写的一些代码了。

　　5、更少的“仓库污染”

　　有时候你要做一个模块，它不是太大，所以没有必要为它新建一个 branch ，但是它又不是那么小，不可能一次提交就做好。于是便会提交一些不完整的代码到仓库，有时候会导致整个程序无法运行，严重影响团队里其他人的开发。大多数人在这种情况下的解决办法都是写完之后再提交。但是作为习惯了版本控制的人来说，进行不计后果的大幅修改是经常的事情，到后来突然发现自己先前的代码没有提交，就后悔莫及了。如果是分布式系统的话就不会存在这样的问题，因为本地仓库的修改不会影响到别人的仓库。当你完成并测试以后，就可以在邮件列表里面说：我已经把这个模块做好了。然后感兴趣的人就可以从你这里 pull 你的成果了。

　　虽然网上各种对Git的誉美之词决不止于此，但是在Git的主站上，还是尽可能客观的对Git和Subversion进行了一番比较（GitSvnComparsion）。另外，Subversion目前通过 SVK 也已经提供了一定程度上的源代码库分布式的管理能力，能够实现源代码的离线提交等功能。

　　优点：
　　（1）适合分布式开发，强调个体。
　　（2）公共服务器压力和数据量都不会太大。
　　（3）速度快、灵活。
　　（4）任意两个开发者之间可以很容易的解决冲突。
　　（5）离线工作。