git和SVN的差别

1）GIT是分布式的。SVN不是：

这 是GIT和其它非分布式的版本号控制系统，比如SVN。CVS等。最核心的差别。优点是跟其它同事不会有太多的冲突。自己写的代码放在自己电脑上，一段时间后再提交、合并，也能够不用联网在本地提交。假设你能理解这个概念，那么你就已经上手一半了。须要做一点声明，GIT并 不是眼下第一个或唯一的分布式版本号控制系统。另一些系统。比如Bitkeeper, Mercurial等，也是执行在分布式模式上的。但GIT在这方面做的更好，并且有很多其它强大的功能特征。

GIT跟SVN一样有自己的 集中式版本号库或server。但。GIT更倾向于被使用于分布式模式，也就是每一个开发者从中心版本号库/server上chect out代码后会在自己的机器上克隆一个自己的版本号库。

可以这样说。假设你被困在一个不能连接网络的地方时，你仍然可以提交文件。查看历史版本号记录，创建项 目分支等。

2）GIT把内容按元数据方式存储。而SVN是按文件：

全部的资源控 制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。假设你把.git文件夹的体积大小跟.svn比較，你会发现它们差距非常大。因 为,.git文件夹是处于你的机器上的一个克隆版的版本号库，它拥有中心版本号库上全部的东西。比如标签，分支，版本号记录等。

3）GIT分支和SVN的分支不同：

分支在SVN中一点不特别，就是版本号库中的另外的一个文件夹。假设你想知道是否合并了一个分支。你须要手工执行像这种命令svn propget svn:mergeinfo，来确认代码是否被合并。

然而。处理GIT的分支却是相当的简单和有趣。

你能够从同一个工作文件夹下高速的在几个分支间切换。你非常easy发现未被合并的分支，你能简单而快捷的合并这些文件。

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

4）GIT没有一个全局的版本。而SVN有：

眼下为止这是跟SVN相比GIT缺少的最大的一个特征。

5）GIT的内容完整性要优于SVN：

GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时减少对版本号库的破坏。

6）Git下载下来后。在本地不必联网就能够看到全部的log，非常方便学习，SVN却须要联网；

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

其它差别：

1。速度：

克 隆一份全新的文件夹。以相同拥有五个（才五个）分支来说，SVN是同一时候复製5个版本号的文件，也就是说反复五次相同的动作。而Git仅仅是获取文件的每一个版本号的 元素。然后仅仅加载基本的分支（master）。

在我的经验，克隆一个拥有将近一万个提交（commit），五个分支，每一个分支有大约1500个文件的 SVN，耗了将近一个小时！

而Git仅仅用了区区的1分鐘！

2。

版本号库（repository）：

据我所知，SVN仅仅能有一个指定中央版本号库。当这个中央版本号库有问题时，全部工作成员都一起瘫痪直到版本号库维修完毕或者新的版本号库设立完毕。

而 Git能够有无限个版本号库。或者，更正确的说法，每个Git都是一个版本号库，差别是它们是否拥有活跃文件夹（Git Working Tree）。假设主要版本号库（比如：置於GitHub的版本号库）发生了什麼事，工作成员仍然能够在自己的本地版本号库（local repository）提交，等待主要版本号库恢复就可以。工作成员也能够提交到其它的版本号库！

3。

分支（Branch）

在SVN，分支是一个完整的文件夹。

且这个文件夹拥有完整的实际文件。假设工作成员想要开啟新的分支，那将会影响“全世界”！

每一个人都会拥有和你一样的分支。

假设你的分支是用来进行破坏工作（安检測试），那将会像传染病一样。

而 Git，每一个工作成员能够随意在自己的本地版本号库开啟无限个分支。

举例：当我想尝试破坏自己的程序（安检測试）。而且想保留这些被改动的文件供日后使用， 我能够开一个分支。做我喜欢的事。全然不需操心妨碍其它工作成员。仅仅要我不合并及提交到主要版本号库，没有一个工作成员会被影响。等到我不须要这个分支时， 我仅仅要把它从我的本地版本号库删除就可以。无痛无痒。

Git的分支名是能够使用不同名字的。比如：我的本地分支名為testing，而在主要版本号库的名字事实上是master。

最值得一提。我能够在Git的随意一个提交点（commit point）开啟分支。（当中一个方法是使用gitk –all 可观察整个提交记录，然后在随意点开啟分支。）

4。提交（Commit）

在SVN。当你提交你的完毕品时。它将直接记录到中央版本号库。

当你发现你的完毕品存在严重问题时，你已经无法阻止事情的发生了。

假设网路中断，你根本没办法提交！

而Git的提交全然属於本地版本号库的活动。而你仅仅需“推”（git push）到主要版本号库就可以。

Git的“推”事实上是在运行“同步”（Sync）。

5。又一次设立起点（Rebase）

我没在SVN尝试过。不知道有没有这种功能。

在 Git，假设你想把别人的最新提交设立為如今这个分支的起点，仅仅要运行git rebase branch_name 就可以。

这个和合并（merge）不同点是。merge会根据改动的时间视為最新，而Rebase会要求你去解决两方都有改动过的地方的矛盾 （conflict）。

A - B - E

\- C - D

A - B - E

\ - C - D

6。系统档案

SVN会在每个文件夹置放一个.svn。假设想移除这些.svn是非常累的。

而Git会在文件夹起点拥有一个.git文件夹，以及.gitignore。

对我而言。管理一个Git 的版本号库是非常easy的事。

以下有一篇文章这样讨论，楼主觉得SVN没什么用，我比較认同Ghoststears的观点。

有了GIT，SVN纯粹一垃圾

Ghoststears：

不论什么事情。归根结底都是人的问题，工具仅仅是工具。

SVN 是集中式的，会出现你说的耦合。

但从另外一个方面来说，这也要求开发者代码的规范：不要一个函数干非常多事情，不要一个文件写非常多个类。

另外，将不可执行的代码提交到不论什么版本号控制系统中都是没有意义的。这也就是版本号控制的核心思想之中的一个。

也就是提交的粒度：原子性。所谓的原子性。也就是完毕 一件任务，这个任务能够是一个函数声明。也能够是一个函数的实现。亦或是一个子系统。但这个任务的完毕的标志就是代码能够执行。不能执行的代码，最多也就 是完毕了半个任务。这个是不符合版本号控制思想的。

试想，你 update 到某一个 version 的时候，代码居然是不能执行的，是何心情？？？

将不能执行的代码提交，全然是开发者素养或者公司管理流程、机制的问题。

另外。非常多人都强调：我晚上下班了要在家里干活，不能提交！！

。来抨击集中式版本号控制工具。且不说对待工作和生活态度。

先看看国内的企业，防员工如防贼的多的去了。

有多少人能带着笔记本，把公司的源码签出来呢？？？

版本号控制系统中。工具仅仅是当中一环。要结合公司的策略来选用合适的工具。

版本号控制 != 版本号控制工具 !!!= 源码管理。

最后，人各有喜好。上纲上线的，全然没有必要。

參考：

http://blog.csdn.net/a117653909/article/details/8952183

http://wuzhangshu927.blog.163.com/blog/static/1142246872011621113641834/

http://www.cnblogs.com/qinfengxiaoyue/p/3450194.html