背景

在日常运维工作中，经常会用到版本控制系统，目前用到最广泛的版本控制器就是SVN和Git,那么这两者之间有什么不同之处呢？

Git

介绍

Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。 也是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。

特点

Git中每个克隆(clone)的版本库都是平等的。可以从任何一个版本库的克隆来创建属于自己的版本库，同时你的版本库也可以作为源提供给他人。Git的每一次提取操作，实际上都是一次对代码仓库的完整备份。提交完全在本地完成，无须别人给授权，甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支。Git的提交不会被打断，PUSH给他人或者他人PULL你的版本库，合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成。冲突解决不再像是SVN一样的提交竞赛，而是在需要的时候才进行合并和冲突解决。Git 也可以模拟集中式的工作模式，该模式非常灵活Git版本库统一放在服务器中可以为 Git 版本库进行授权，谁能创建版本库，谁能向版本库PUSH，谁能够读取（克隆）版本库团队的成员将自己的改动推（PUSH）到服务器的版本库中，当其他人和版本库同步（PULL）时，会自动获取改变脱离Git服务器所在网络的情况下，如移动办公／出差时，照常使用代码库Git提供 rebase 命令，可以让你的改动看起来是基于最新的代码实现的改动

优点：

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

缺点：

学习周期相对而言比较长。不符合常规思维。代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

架构

核心概念

Git核心概念工作区、暂存区、版本库、远程仓库，Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

Workspace： 工作区，就是你平时存放项目代码的地方Index / Stage： 暂存区，用于临时存放改动，事实上它只是一个文件，保存即将提交到文件列表信息Repository： 仓库区（或版本库），就是安全存放数据的位置，这里面有所有提交的版本数据。其中HEAD指向最新放入仓库的版本Remote： 远程仓库，托管代码的服务器，可以简单认为是项目组中的一台电脑用于远程数据交换

工作流程

从远程仓库中克隆 Git 资源作为本地仓库；从本地仓库中checkout代码然后进行代码修改；在提交本地仓库前先将代码提交到暂存区；提交修改，提交到本地仓库；本地仓库中保存修改的各个历史版本；在需要和团队成员共享代码时，可以将修改代码push到远程仓库。

工作流

单分支 Git 工作流，最基本的 Git 工作流是只有一个分支 - master 分支的模式。开发人员直接提交 master 分支并使用它来部署到预发布和生产环境。由于只有一个分支，因此这里实际上没有任何流程。这样一来，你就可以轻松开始使用 Git。但是在代码上进行协作将导致多种冲突、生产环境出现 bug 的概率会大增、维护干净的代码将更加困难

并行功能 Git 分支工作流，当你有多个开发人员在同一个代码库上工作时，Git 功能分支工作流将成为必选项，使用此工作流的优点是，Git 功能分支工作流使你可以在代码上进行协作，而不必担心代码冲突。

带有 Develop 分支的 Git 功能分支工作流，此工作流是开发团队中比较流行的工作流之一。它与 Git 功能分支工作流相似，但它的 develop 分支与 master 分支并行存在。在此工作流中，master 分支始终代表生产环境的状态。每当团队想要部署代码到生产环境时，他们都会部署 master 分支。此工作流的优点是，它使团队能够一致地合并所有新功能，在预发布阶段对其进行测试并部署到生产环境中

Subversion

介绍

Subversion(简称SVN)，Subversion是一个版本控制系统，相对于的RCS、CVS，采用了分支管理系统，它的设计目标就是取代CVS。互联网上免费的版本控制服务多基于Subversion。在Subversion管理下，文件和目录可以超越时空。Subversion将文件存放在中心版本库里，这个版本库很像一个普通的文件服务器，不同的是，它可以记录每一次文件和目录的修改情况，这样就可以借此将数据恢复到以前的版本，并可以查看数据的更改细节。正因为如此，许多人将版本控制系统当作一种神奇的“时间机器”。

特点

每个版本库有唯一的URL，每个用户都从这个地址获取代码和数据； 获取代码的更新，也只能连接到这个唯一的版本库，同步以取得最新数据； 提交必须有网络连接（非本地版本库）； 提交需要授权，如果没有写权限，提交会失败； 提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类； 冲突解决是一个提交速度的竞赛，手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。

优点：

管理方便，逻辑明确，符合一般人思维习惯。易于管理，集中式服务器更能保证安全性。代码一致性非常高。适合开发人数不多的项目开发。

缺点：

服务器压力太大，数据库容量暴增。如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。

架构

核心概念

repository（源代码库）:源代码统一存放的地方Checkout（提取）:当你手上没有源代码的时候，你需要从repository checkout一份Commit（提交）:当你已经修改了代码，你就需要Commit到repositoryUpdate (更新):当你已经Checkout了一份源代码， Update一下你就可以和Repository上的源代码同步，你手上的代码就会有最新的变更

核心组件

SVN，命令行客户端程序。SVNversion，此工具用来显示工作拷贝的状态（用术语来说，就是当前项目的修订版本）。SVNlook，直接查看Subversion版本库的工具。SVNadmin，建立、调整和修复Subversion版本库的工具。SVNdumpfilter，过滤Subversion版本库转储数据流的工具。mod_dav_SVN，ApacheHTTP服务器的一个插件，使版本库可以通过网络访问。SVNserve，一个单独运行的服务器程序，可以作为守护进程或由SSH调用，这是另一种使版本库，可以通过网络访问的方式。SVNsync，一个通过网络增加镜像版本库的程序。

架构图

一端是保存你所有纳入版本控制的数据的Subversion版本库，在另一端是你的Subvesion客户端程序，管理着所有纳入版本控制数据的本地影射（叫做“工作拷贝”），在这两极之间是各种各样的版本库访问（RA）层，一些使用电脑网络通过网络服务器访问版本库，一些则绕过网络服务器直接访问版本库。

总结

Git是分布式的，SVN是集中式的：这是 Git 和 SVN 最大的区别。若能掌握这个概念，两者区别基本搞懂大半。因为 Git 是分布式的，所以 Git 支持离线工作，在本地可以进行很多操作，包括接下来将要重磅推出的分支功能。而 SVN 必须联网才能正常工作。

Git复杂概念多，SVN简单易上手：所有同时掌握 Git 和 SVN 的开发者都必须承认，Git 的命令实在太多了，日常工作需要掌握add,commit,status,fetch,push,rebase等，若要熟练掌握，还必须掌握rebase和merge的区别，fetch和pull的区别等，除此之外，还有cherry-pick，submodule，stash等功能，仅是这些名词听着都很绕。在易用性这方面，SVN 会好得多，简单易上手，对新手很友好。但是从另外一方面看，Git 命令多意味着功能多，若我们能掌握大部分 Git 的功能，体会到其中的奥妙，会发现再也回不去 SVN 的时代了。

Git分支廉价，SVN分支昂贵：在版本管理里，分支是很常使用的功能。在发布版本前，需要发布分支，进行大需求开发，需要 feature 分支，大团队还会有开发分支，稳定分支等。在大团队开发过程中，常常存在创建分支，切换分支的需求。Git 分支是指针指向某次提交，而 SVN 分支是拷贝的目录。这个特性使 Git 的分支切换非常迅速，且创建成本非常低。而且 Git 有本地分支，SVN 无本地分支。在实际开发过程中，经常会遇到有些代码没写完，但是需紧急处理其他问题，若我们使用 Git，便可以创建本地分支存储没写完的代码，待问题处理完后，再回到本地分支继续完成代码。