使用Git替代SVN的可行性分析
版本库本地化 ——每个开发者都拥有自己的版本控制库，在自己的版本库上可以任意的执行提交代码、创建分支等行为。例如，开发者认为自己提交的代码有问题？没关系，因为版本库是自己的，回滚历史、反复提交、归并分支并不会影响到其他开发者。 因为是私有的本地版本库，因此实现“真正的”脱机工作 成为可能。只有在必要的时候，才会和公共版本库合并，每个开发者会在本地保存一个公共版本库的镜像，在提交时可与公共版本库同步以更新这个镜像，可以基于这个镜像和自己的私有版本库创建公共版本库的更新补丁 ，这个补丁可以以邮件、HTTP等多种传送方式去升级公共版本库。
Git的“比较”功能很强大，归并文件速度比SVN要快 。
Git的无污染性 ，git对于每个工程只会产生一个.git目录，这个工程所有的版本控制信息都在这个目录中，不会像SVN那样在每个目录下都产生.svn目录。
目前，Git的不足之处在于：
Git缺乏细致的权限管理功能，这个与Git的产生背景及文化有关，Git秉承Linux自由开放的精神，本身没有权限管理的概念，而且估计很难在短时间内改变，只能期待第三方工具能弥补这个缺陷。例如在Linux下，Git版本库的权限管理一般是通过Linux系统共本身的用户权限管理来做的。SVN则有很多第三方管理工具供选择。
Git虽然能归并文件，但不提供图形化的归并（merge）工具。例如，如果需要进行文件的人工比较，在windows下一般需要借助 TortoiseMerge, Araxis Merge 之类的工具完成……而我们知道，人工比较是必不可少的。
Git的Eclipse插件功能有限，很多操作还需要靠命令行，据说还有些bug。
结论
Git是真正的分布式版本管理工具 ，每个人都有自己的代码库，跟SVN不同。这个区别带来的最大好处就是跟踪本地的修改过程非常方便，而SVN里不同代码库之间不能切换。但是SVN客户端的用户界面比Git友好得多，特别是SVN建立在大家普遍比较熟悉的CVS模型之上。
Git非常适合像 Linux Kernel 这样的开发组织形式高度分散，严重依赖 Email 来进行交流的项目。
Git同时也适合那些通过Email沟通的小团队开发，Git为之提供了不少贴心的小功能，这里就不多说了。
公司开发是相对集中的工作模式，对时间和协作效率的要求比较高 ，还是采用 CVS, SVN 这样的基于中央版本控制库的工具比较好，毕竟它们比Git在这方面更成熟，更友好。
一些Git资源
页:
[1]