vs svn 西安乾泽科技：关于 Git 你需要知道的(2)

对比标签 Diff two tags against each other (v1.9.1.0/v1.9.3.0 )1.17 83.57 71x

提交历史 (50) Log of the last 50 commits (19k of output) 0.01 0.3831x

提交历史 (全部) Log of all commits (26,056 commits – 9.4M of output)0.52 169.20 325x

提交历史 (文件) Log of the history of a single file (array.c – 483revs) 0.60 82.84 138x

更新 Pull of Commit A scenario (113 files changed, 2164+, 2259-)0.90 2.82 3x

Blame Line annotation of a single file (array.c) 1.91 3.041x

你需要注意的是，这已经是 SVN 最好的运行场景了 — 一个没有任何负载的服务器，客户端和服务器之间的网络带宽达到80MB/s。上文中的所有指标在受网络波动，或者在一个更差的网络环境下 SVN 的表现都更差，然而 Git这边几乎所有的指标都不受影响。

很明显，在这些最常用的版本控制工具的操作中，甚至是在SVN 的理想使用环境下，**Git在很多方面都大幅领先**。

一个 Git 比 SVN 慢的地方是初始化 clone 仓库。在这种情况下，Git是在下载整个仓库历史而不是仅仅是最新版本的代码。上文中的表格所示，仅仅执行一次的操作影响并不是很大。

操作 描述 Git（Shallow Clone） Git SVN

Clone Git Clone 以及 shallow clone(浅 clone) vs SVN checkout 21.0107.5 14.0

大小(M) 客户端在 clone/checkout 后的文件大小 (以 M 为单位) 181.0 132.0

另外一个有趣的点是，Git 和 SVN 在 Clone 或者 Checkout 到本地后的文件大小几乎差别不大，要知道对于Git 来说，本地可是包含了整个项目历史。这也展示了 Git 在文件压缩和存储上的超高效率。

分布式

Git 最棒的特性之一就是分布式。这意味着，你要 clone 整个仓库而不是仅仅 checkout分支的最新头部版本。

多个备份

在日常的使用场景中 Git往往有多个备份。这意味着就算在使用一个中央存储式的工作流，每一个用户都在本地有一个服务器上的完整备份。这里的任意一个版本都可以在服务器端数据损坏或者丢失的时候推送回服务器以挽救损失。事实上，只要你的仓库不是只有一个copy，Git 就不会存在单点问题。

任意工作流

因为 Git 拥有分布式特性和极好的分支系统，你可以在此基础上轻松实现大量的工作流模型。

Subversion（SVN） 风格工作流

集中式存储的工作流非常常见，特别是对于那些从传统的集中式代码版本管理系统转过来使用 Git 的人。Git一样可以提供这种工作形式：每次 Push必须要更新到远程仓库的最新版本。所以说大家还是像以前一样使用集中式存储的工作流往同一个服务器上 Push 代码依然没问题。

整合管理者工作流

另外一个常见的 Git 工作流是整合工作流。主要的仓库有一个单一的开发者维护（维护者）。其他若干开发者从这个仓库clone，然后推送到他们自己的完全独立的仓库里面，最后请求维护者从主要仓库 Pull 那些他们在各自的仓库里面的改动。这种形式往往在GitHub 上以开源的形式进行协作。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-63437-2.html