SVN和Git的异同

其实Git和SVN还是挺像的，都有提交，合并等操作，看来这是源码管理工具的基本操作。

1. Git是分布式的，SVN是集中式的，好处是跟其他同事不会有太多的冲突，自己写的代码放在自己电脑上，一段时间后再提交、合并，也可以不用联网在本地提交；

2. Git下载下来后，在本地不必联网就可以看到所有的log，很方便学习，SVN却需要联网；

3. Git鼓励分Branch，而SVN，说实话，我用Branch的次数还挺少的，SVN自带的Branch merge我还真没用过，有merge时用的是Beyond Compare工具合并后再Commit的；

4. Tortoise也有出Git版本，真是好东西；

5. SVN在Commit前，我们都建议是先Update一下，跟本地的代码编译没问题，并确保开发的功能正常后再提交，这样其实挺麻烦的，有好几次同事没有先Updata，就
Commit了，发生了一些错误，耽误了大家时间，Git可能这种情况会少些。

大家也可以搜一搜Git和SVN命令的比对。

下面有一篇文章这样讨论，楼主认为SVN没什么用，我比较认同Ghoststears的观点。

有了GIT，SVN纯粹一垃圾

Ghoststears：

任何事情，归根结底都是人的问题，工具只是工具。

SVN 是集中式的，会出现你说的耦合。但从另外一个方面来说，这也要求开发人员代码的规范：不要一个函数干很多事情，不要一个文件写很多个类。

另外，将不可运行的代码提交到任何版本控制系统中都是没有意义的。这也就是版本控制的核心思想之一。也就是提交的粒度：原子性。所谓的原子性，也就是完成一件任务，这个任务可以是一个函数声明，也可以是一个函数的实现，亦或是一个子系统。但这个任务的完成的标志就是代码可以运行，不能运行的代码，最多也就是完成了半个任务。这个是不符合版本控制思想的。试想，你 update 到某一个 version 的时候，代码竟然是不能运行的，是何心情？？？

将不能运行的代码提交，完全是开发人员素质或者公司管理流程、机制的问题。

版本控制系统中，工具只是其中一环。要结合公司的策略来选用合适的工具。版本控制 != 版本控制工具 !!!= 源代码管理。

Git --- The stupid content tracker, 傻瓜内容跟踪器。Linus 是这样给我们介绍 Git 的，但我认为他是反指。

Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。

实际上内核开发团队决定开始开发和使用 Git 来作为内核开发的版本控制系统的时候，世界开源社群的反对声音不少，最大的理由是 Git 太艰涩难懂，从 Git 的内部工作机制来说，的确是这样。但是随着开发的深入，Git 的正常使用都由一些友好的脚本命令来执行，使 Git 变得非常好用，即使是用来管理我们自己的开发项目，Git 都是一个友好，有力的工具。现在，越来越多的著名项目采用 Git 来管理项目开发，例如：wine, U-boot 等，详情看 http://www.kernel.org/git

作为开源自由原教旨主义项目，Git 没有对版本库的浏览和修改做任何的权限限制，通过其他工具也可以达到有限的权限控制，比如：gitosis。原本 Git的使用范围只适用于 Linux / Unix 平台，但逐步并成熟了在 Windows 平台下的使用，主要归功于Cygwin与msysgit环境与TortoiseGit这样易用的 GUI 工具。其实 Git 的源代码中已经加入了对 Cygwin 与 MingGW 编译环境的支持并被逐步完善，对于 Windows 使用者是个福音。

题外： 
GIT专门用于源代码管理。