Skip to content

Commit b46fb41

Browse files
committed
Why-git-is-batter: add scability comparation
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
1 parent 7fd41ff commit b46fb41

File tree

1 file changed

+12
-6
lines changed

1 file changed

+12
-6
lines changed

_posts/2012-04-12-why-git-is-better-than-svn.md

Lines changed: 12 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -200,7 +200,13 @@ SVN对分支当做路径来授权,造成管理的负担(参见 [前面的描
200200

201201
## Git能做到,而SVN难以做到的事情 ##
202202

203-
### Git分支功能最为强大,分支管理能力让SVN望尘莫及 ###
203+
### 优势1:使用Git,团队规模不受版本库工具自身的限制 ###
204+
205+
在实际应用中,一个SVN版本库的每小时提交次数存在上限。如果无冲突合并再提交需用时30秒、冲突解决再提交用时300秒,这个上限可能是每小时40个提交。据此一个相对密集开发的版本库拥有四五十个提交账号可能就是极限。
206+
207+
Git的提交是在本地完成的,加之可以采用版本库分级控制的分布式开发模型,因此只有天空才是极限。
208+
209+
### 优势2:Git分支功能最为强大,分支管理能力让SVN望尘莫及 ###
204210

205211
Git可以很容易地对比两个分支,知道一个分支中哪些提交尚未合并到另一分支,反之亦然。
206212

@@ -216,15 +222,15 @@ Git可以很容易地对比两个分支,知道一个分支中哪些提交尚
216222
在SVN中一次提交可以同时更改主线(/trunk)和分支中的内容,
217223
所以判断一个分支中哪些提交未合并到另外的分支,完全不能对SVN抱有希望。
218224

219-
### Git可以实现更好的发布控制 ###
225+
### 优势3:Git可以实现更好的发布控制 ###
220226

221227
针对同一个项目,Git可以设置不同层级的版本库(多版本库),
222228
或者通过不同的分支(多分支)实现对发布的控制。
223229

224230
* 设置只有发布管理员才有权限推送的版本库或者分支,用于稳定发布版本的维护。
225231
* 设置只有项目经理、模块管理员才有权推送的版本库或者分支,用用于整合测试。
226232

227-
### 隔离开发,提交审核 ###
233+
### 优势4:隔离开发,提交审核 ###
228234

229235
如何对团队中的新成员的开发进行审核呢?在Git服务器上可以实现用户自建分支和自建版本库的功能,
230236
这样团队中的新成员既能将本地提交推送到服务器以对工作进行备份,
@@ -233,7 +239,7 @@ Git可以很容易地对比两个分支,知道一个分支中哪些提交尚
233239
审核新成员提交时,从其个人版本库或个人分支获取(fetch)提交,从提交说明、代码规范、编译测试
234240
等多方面对提交逐一审核。审核通过执行 ``git merge`` 命令合并到开发主线中。
235241

236-
### 对合并更好的支持,更少的冲突,更好的冲突解决 ###
242+
### 优势5:对合并更好的支持,更少的冲突,更好的冲突解决 ###
237243

238244
因为Git基于对内容的追踪而非对文件名追踪,所以遇到一方或双方对文件名更改时,
239245
Git能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突,
@@ -243,7 +249,7 @@ Git的基于DAG(有向非环图)的设计比SVN的线性提交提供更好
243249
避免不必要的冲突,提高工作效率。这是开发者选择Git、抛弃SVN的重要理由。
244250

245251

246-
### 保证已修复Bug不再重现 ###
252+
### 优势6:保证已修复Bug不再重现 ###
247253

248254
以为创建完毕里程碑标签(tag)便完成软件版本的发布是有风险的,
249255
往往会由于之前的版本(维护版本)中的一些 Hotfix
@@ -259,7 +265,7 @@ Git分支和合并追踪可以解决这个问题。例如用 maint 分支跟踪
259265
如果合并成功,代表发行版 v1.6.4 包含了所有前一个发行版的提交。
260266
反之说明前一个发行版某个或某些Hotfix提交尚未合并到最新发行版中。
261267

262-
### 版本库的安全性 ###
268+
### 优势7:版本库的安全性 ###
263269

264270
SVN版本库安全性很差,是管理员头痛的问题。
265271

0 commit comments

Comments
 (0)