集中式的版本控制系统都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。
中央服务器的单点故障。
若是宕机一小时，那么在这一小时内，谁都无法提交更新、还原、对比等，也就无法协同工作。如果中央服务器的磁盘发生故障，并且没做过备份或者备份得不够及时的话，还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人提取出来。
Subversion 原理上只关心文件内容的具体差异。每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容。
Git 记录版本历史只关心文件数据的整体是否发生变化。Git 不保存文件内容前后变化的差异数据。
实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一连接。
在分布式版本控制系统中，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程。
另外，因为 Git 在本地磁盘上就保存着所有有关当前项目的历史更新，并且 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网，所以处理起来速度飞快。用 SVN 的话，没有网络或者断开VPN你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程的镜像仓库。换作其他版本控制系统，这么做几乎不可能，抑或是非常麻烦。
Subversion 的工作区和版本库是截然分开的，而 Git 的工作区和版本库是如影随形的。
Subversion 的工作区和版本库物理上分开：Subversion 的版本库和工作区是存储在不同路径下，一般是在不同的主机中，Subversion 的企业级部署中，版本库在服务器上，只能通过 https, http, svn 等协议访问，而不能直接被用户接触到。
Subversion 的工作区是一份版本库在某个历史状态下的快照，如：版本库最新的数据检出到工作区。Subversion 的工作区中每一个目录下都包含一个名为 .svn 的控制目录（隐藏的目录），该目录的作用是：
Subversion 的 .svn 控制目录会引入很多麻烦：
Git 的版本库和工作区在同一个目录下，工作区的根目录有一个 .git 的子目录，这个名为 .git 的目录就是版本库本身，它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。所以千万要小心删除这个文件。
工作区中其他文件为工作区文件，可能是从 .git 中检出的，或者是要检入的，或者是运行产生的临时文件等。
版本库可以脱离工作区而存在，成为 bare（赤裸）版本库。可以用 –bare 参数来创建。但是工作区不能脱离版本库而存在，即工作区的根目录下必须有一个名为 .git 的版本库克隆文件。
Git 的版本库因为就在工作区中，能直接被用户接触到。
Git 的工作区中只在工作区的根目录下有一个 .git 目录，此外再无任何控制目录。Git 工作区下唯一的 .git 目录是版本库，并非 .svn 的等价物，如果删除了 .git 目录，而又没有该版本库的其他镜像（克隆）的话，你破坏了整个历史，版本库也永远的失去了。
Git 在本地的 .git 版本库，提供了完全的改动历史。除了和其他人数据交换外，任何版本库相关的操作都在本地完成，更多的本地操作，避免了冗长的网络延迟，大大节省了时间。例如：查看 log，切换到任何历史版本等操作都无须连接网络。
Git 如何保证安全：本地创建一个 Git 库，因为工作区和库是在同一个目录中，如果工作区删除了，或者所在的磁盘分区格式化了，数据不是全都没有了么？其实我们可以这样做：
SVN 的全局版本号和 CVS 的每个文件都独立维护一套版本号相比，是一个非常大的进步。在看似简单的全局版本号的背后，是 Subversion 提供对于事物处理的支持，每一个事物处理（即一次提交）都具有整个版本库全局唯一的版本号。
Git 的版本号则更进一步，版本号是全球唯一的。Git 对于每一次提交，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，得到一个 40 位的十六进制字符串，Git 将此字符串作为版本号。
所有保存在 Git 数据库中的数据都是用此 40 位的哈希值作索引的，而不是靠文件名。
使用哈希值作版本号的好处就是对于一个分布式的版本控制系统，每个人每次提交后形成的版本号都不会出现重复。另一好处是保证数据的完整性，因为哈希值是根据内容或目录结构计算出来的，所以我们还可以据此来判断数据内容是否被篡改。
SVN 的版本号是连续的，可以预判下一个版本号，而 Git 的版本号则不是。因为 subversion 是集中式版本控制，很容易实现版本号的连续性。Git 是分布式的版本控制系统，而且 Git 采用 40 位长的哈希值作为版本号，每个人的提交都是各自独立完成的，没有先后之分（即使提交有先后之分，也由于 PUSH/PULL 的方向和时机而不同）。
Git 的版本号虽然不连续，但是是有线索的，即每一个版本都有对应的父版本（一个或者两个），进而可以形成一个复杂的提交链。
Git 的版本号简化：Git 可以使用从左面开始任意长度的字串作为简化版本号，只要该简化的版本号不产生歧义。一般采用 7 位的短版本号（只要不会出现重复的，你也可以使用更短的版本号）。
Subversion 可以将整个库检出到工作区，也可以将某个目录检出到工作区。对于要使用一个庞大、臃肿的版本库的用户来说，部分检出是非常方便和实际的。但是 Git 只能全部检出，不支持按照目录进行的部分检出。
在 SVN 中，从仓库 checkout 的一个工作树，每个子目录下都维护着自己的 .svn 目录，记录着该目录中文件的修改情况以及和服务器端仓库的对应关系。所以 SVN 可以 checkout 部分路径下的内容（部分检出），而不用 checkout 整个版本库或分支。
Subversion 有一条命令：svn export ，可以将 subversion 版本库的一个目录下所有内容导出到指定的目录下。Subversion 需要 svn export 命令是因为该命令可以导出一个干净的目录，即不包含 .svn 目录（包含配置文件和文件原始拷贝）。
Git 没有部分检出，这并不是说只有将整个库克隆下来才能查看文件。有很多 git 工具，提供直接浏览 git 库的功能，例如 gitweb, trac 的 git 版本库浏览, redmine 的 git 版本库浏览。
Git-submodule 可以实现版本库的模块化：Git 通过子模块处理这个问题。
子模块允许你将一个Git 仓库当作另外一个 Git 仓库的子目录。这允许你克隆另外一个仓库到你的项目中并且保持你的提交相对独立。
Git 为什么没有实现 svn export 的功能？由于 git 的本地仓库信息完全维护在 project 根目录的 .git 目录下，（不像 svn 一样，每个子目录下都有单独的 .svn 目录）。所以，只要 clone，checkout 然后删除 .git 目录就可以了。
在 SVN 中，因为只有一个中心仓库，所以所谓的远程更新，也就是 svn update ,通过此命令来使工作区和版本库保持同步。
对于 git 来说，别人的改动是存在于远程仓库上的，所以 git checkout 命令尽管在某些功能上和 svn 中的 update 类似（例如取仓库特定版本的内容），但是在远程更新这一点上，还是不同的，不属于 git checkout 的功能涵盖范围。
Git 使用 git fetch 和 git pull 来完成远程更新任务，fetch 操作只是将远程数据库的 object 拷贝到本地，然后更新 remotes head 的 refs，git pull 的操作则是在 git fetch 的基础上对当前分支外加 merge 操作。
对于 SVN 来说，由于是中心式的仓库管理形式，所以并不存在特殊的远程提交的概念，所有的 commit 操作都可以认为是对远程仓库的更新动作。在工作区中对文件进行添加、修改、删除操作要同步到版本库，必须使用 commit 命令。
Git 管理项目时，文件在三个工作区域中流转：Git 的本地数据目录，工作目录以及暂存区域。暂存区域（stage）是介于 workcopy 和 版本库 HEAD 版本的一种中间状态。所谓的暂存区域只不过是个简单的文件，一般都放在 git 目录中。有时候人们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。
要将一个文件纳入版本管理的范畴，首先是要用 git add 将文件纳入 stage 的监控范围，只有更新到 stage 中的内容才会在 commit 的时候被提交。另外，文件本身的改动并不会自动更新到 stage 中，每次的任何修改都必须重新更新到 stage 中去才会被提交。对于工作区直接删除的文件，需要用 git rm 命令进行标记，在下次提交时，在版本库中删除。
我们可以从文件所处的位置来判断其状态：如果是 git 目录中保存着的特定版本文件，就属于已提交状态；如果作了修改并已放入暂存区域，就属于已暂存状态；如果自上次取出后，作了修改但还没有放到暂存区域，就是已修改状态，如果取出后未进行修改则是未修改状态。
在 git 中，因为有本地仓库和 remote 仓库之分，所以也就区别于 commit 操作，存在额外的 push 命令，用于将本地仓库的数据更新到远程仓库中去。git push 可以选择需要提交的、更新的分支以及制定该分支在远程仓库上的名字。
几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。在很多版本控制系统中，这是个昂贵的过程，常常需要创建一个源代码目录的完整副本，对大型项目来说会花费很长时间。
轻量级分支/里程碑的含义是，创建分支/里程碑的复杂度是 o(1)，不会因为版本库的愈加庞大而变得缓慢。在 CVS 中，创建分支的复杂度是 o(n) 的，导致大的版本库的的分支创建非常缓慢。
Subversion 轻量级分支和里程碑的实现是通过 svn cp 命令，即带历史的拷贝就是创建快速创建分支和里程碑的秘籍。Subversion 的版本库有特殊的设计，当你复制一个目录，你不需要担心版本库会变得十分巨大— Subversion 并不是拷贝所有的数据，相反，它只是建立了一个已存在目录树的入口。这种 “廉价的拷贝” 就是创建分支/里程碑是轻量级的原因。
由于 Svn 的分支和标签是来自目录拷贝，约定俗成是拷贝在 branches/ 和 tags/目录下。所谓分支，tag 等概念都只是仓库中不同路径上的一个对象或索引而已，和普通的路径并没有什么本质的区别，谁也不能阻止在一个提交中同时修改不同分支中的数据。
里程碑是对某个历史提交所起的一个别名，作为历史的标记，是不应该被更改的。svn 的里程碑要建立到 tags/ 目录下，要求不要在 tags/ 下的里程碑目录下进行提交。但是谁也阻止不了对未进行权限控制的里程碑的篡改。
Git 中的分支实际上仅是一个包含所指对象校验和（40 个字符长度 SHA-1 哈希值）的文件，所以创建和销毁一个分支就变得非常廉价。说白了，新建一个分支就是向一个文件写入 41 个字节（版本号外加一个换行符）那么简单，自然速度就很快了。
Git 的实现与项目复杂度无关，它永远可以在几毫秒的时间内完成分支的创建和切换。这和大多数版本控制系统形成了鲜明对比。
Git 的分支是完全隔离的，而 Subversion 则没有。分支本来就应该是相对独立的命名空间，一个提交一般只能发生在一个分支中。在 Git 中，其内部的对象层级依赖关系或许和 SVN 类似，但是其工作树的视图表现形式和 SVN 完全不同。工作树永远是一个完整的分支，不同的分支由不同的 head 索引去构建，你不可能在工作树中同时获得多个分支的内容。
Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。
Git 的里程碑是只读的，Git 完全遵守历史不可更改这一时空法则。用户不能向 git 的里程碑中提交，否则里程碑就不是标记，而成了一个分支。当然 Git 允许用户删除里程碑再重新创建指定到不同历史提交。
SVN中 提供了一个功能 switch，使用 switch 可以在同一个工作树上，在不同的分支中进行切换。Git 在分支中进行切换使用的命令是 checkout。
Git 和 Svn 的分支实现机制完全的不同，这也直接导致了 SVN 在分支合并中困难重重。尽管在 SVN 1.5 之后，通过 svn:mergeinfo 属性引入了合并追踪机制，但是在特定情况下，合并仍会出现很多困难。
当你在一个分支上工作数周或几个月之后，主干的修改也同时在进行着，两条线的开发会区别巨大，当你想合并分支回主干，可能因为太多冲突，已经无法轻易合并你的分支和主干的修改。
另一个问题，Subversion 不会记录任何合并操作，当你提交本地修改，版本库并不能判断出你是通过 svn merge 还是手工修改得到这些文件。所以你必须手工记录这些信息（说明合并的特定版本号或是版本号的范围）。
要解决以上的问题只有通过有规律的将主干合并到分支来避免，制定这样一个政策：每周将上周的修改合并到分支，注意这样做时需要小心，你必须手工记录合并的过程，以避免重复的合并，你需要小心的撰写合并的日志信息，精确的描述合并包括的范围。这样做看起来有点像是胁迫。
SVN 的版本号是连续的版本号。每一次新的提交都会版本号 +1 ，而无论这个提交是在哪个分支中进行的。SVN 一个提交可以同时修改不同分支的不同文件，因为提交命令可以在 /trunk, /branches, /tags 的上一级目录执行。
在 git 版本库中创建分支的成本几乎为零，所以，不必吝啬多创建几个分支。当第一次执行 git-init 时，系统就会创建一个名为 ”master” 的分支。 而其它分支则通过手工创建。下面列举一些常见的分支策略。
在 Subversion 中一旦完成向服务器的数据提交，你就没有办法再从客户端追回，只能在后续的提交中修正（回退或者修改）等。因为 Subversion 作为集中式的版本控制，不能允许个人对已提交的数据进行篡改。Subversion 具有一个非常重要的特性就是它的信息从不丢失，即使当你删除了文件或目录，它也许从最新版本中消失了 ，但这个对象依然存在于历史的早期版本中。
Git 则不同，Git 是分布式版本控制系统，代码库是属于个人，允许任意修改。Git 通过对提交建立数字摘要来保证提交的唯一性和不可更改性，通过版本库在多人之间的多份拷贝来保障数据的安全性。Git 可以丢弃最新的一个或几个提交，使用 git reset –hard 命令可以永远丢弃最新的一个或者几个提交。
提交后如果对提交说明不满意，如何实现对提交说明的修改：
Git 可以使用命令 git commit –amend 修改提交说明。
Subversion 也可以修改提交说明，是通过修改提交的 svn:log 版本属性实现的：
Git 可以修改和重构历史提交：使用 Git 本身的 reset 以及 rebase 命令可以修改或者重整/重构历史提交，非常灵活。使用强大的 stg 可以使得历史提交的重构更为简洁，如果您对 stg 或者 Hg/MQ 熟悉的话。
Subversion 修改历史提交，只能由管理员完成。
Subversion 是集中式版本控制系统，从客户端一旦完成提交，就没有办法从客户端撤销提交。但是管理员可以在服务器端完成提交的撤销和修改，但是操作过程和代价较大。
Subversion 通过对文件目录授权来实现权限管理，子目录默认继承父目录的权限。但是也有缺憾，即权限不能在分支中继承，不能对单个文件授权。例如为 /trunk 及其子目录的授权，不能继承到分支或者标签中相应的目录下。
Git 的授权做不到 Subversion 那样精细。Git 的授权模型只能实现非零即壹式的授权，要么拥有全部的写权限，要么没有写权限，要么拥有整个版本库的读权限，要么禁用。
从技术上讲，Git 可能永远也做不到类似 SVN 的路径授权（读授权）：
