@@ -200,7 +200,13 @@ SVN对分支当做路径来授权,造成管理的负担(参见 [前面的描
200
200
201
201
## Git能做到,而SVN难以做到的事情 ##
202
202
203
- ### Git分支功能最为强大,分支管理能力让SVN望尘莫及 ###
203
+ ### 优势1:使用Git,团队规模不受版本库工具自身的限制 ###
204
+
205
+ 在实际应用中,一个SVN版本库的每小时提交次数存在上限。如果无冲突合并再提交需用时30秒、冲突解决再提交用时300秒,这个上限可能是每小时40个提交。据此一个相对密集开发的版本库拥有四五十个提交账号可能就是极限。
206
+
207
+ Git的提交是在本地完成的,加之可以采用版本库分级控制的分布式开发模型,因此只有天空才是极限。
208
+
209
+ ### 优势2:Git分支功能最为强大,分支管理能力让SVN望尘莫及 ###
204
210
205
211
Git可以很容易地对比两个分支,知道一个分支中哪些提交尚未合并到另一分支,反之亦然。
206
212
@@ -216,15 +222,15 @@ Git可以很容易地对比两个分支,知道一个分支中哪些提交尚
216
222
在SVN中一次提交可以同时更改主线(/trunk)和分支中的内容,
217
223
所以判断一个分支中哪些提交未合并到另外的分支,完全不能对SVN抱有希望。
218
224
219
- ### Git可以实现更好的发布控制 ###
225
+ ### 优势3: Git可以实现更好的发布控制 ###
220
226
221
227
针对同一个项目,Git可以设置不同层级的版本库(多版本库),
222
228
或者通过不同的分支(多分支)实现对发布的控制。
223
229
224
230
* 设置只有发布管理员才有权限推送的版本库或者分支,用于稳定发布版本的维护。
225
231
* 设置只有项目经理、模块管理员才有权推送的版本库或者分支,用用于整合测试。
226
232
227
- ### 隔离开发,提交审核 ###
233
+ ### 优势4: 隔离开发,提交审核 ###
228
234
229
235
如何对团队中的新成员的开发进行审核呢?在Git服务器上可以实现用户自建分支和自建版本库的功能,
230
236
这样团队中的新成员既能将本地提交推送到服务器以对工作进行备份,
@@ -233,7 +239,7 @@ Git可以很容易地对比两个分支,知道一个分支中哪些提交尚
233
239
审核新成员提交时,从其个人版本库或个人分支获取(fetch)提交,从提交说明、代码规范、编译测试
234
240
等多方面对提交逐一审核。审核通过执行 `` git merge `` 命令合并到开发主线中。
235
241
236
- ### 对合并更好的支持,更少的冲突,更好的冲突解决 ###
242
+ ### 优势5: 对合并更好的支持,更少的冲突,更好的冲突解决 ###
237
243
238
244
因为Git基于对内容的追踪而非对文件名追踪,所以遇到一方或双方对文件名更改时,
239
245
Git能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突,
@@ -243,7 +249,7 @@ Git的基于DAG(有向非环图)的设计比SVN的线性提交提供更好
243
249
避免不必要的冲突,提高工作效率。这是开发者选择Git、抛弃SVN的重要理由。
244
250
245
251
246
- ### 保证已修复Bug不再重现 ###
252
+ ### 优势6: 保证已修复Bug不再重现 ###
247
253
248
254
以为创建完毕里程碑标签(tag)便完成软件版本的发布是有风险的,
249
255
往往会由于之前的版本(维护版本)中的一些 Hotfix
@@ -259,7 +265,7 @@ Git分支和合并追踪可以解决这个问题。例如用 maint 分支跟踪
259
265
如果合并成功,代表发行版 v1.6.4 包含了所有前一个发行版的提交。
260
266
反之说明前一个发行版某个或某些Hotfix提交尚未合并到最新发行版中。
261
267
262
- ### 版本库的安全性 ###
268
+ ### 优势7: 版本库的安全性 ###
263
269
264
270
SVN版本库安全性很差,是管理员头痛的问题。
265
271
0 commit comments