为什么说 Git 比 SVN 更好.docx
- 文档编号:11306640
- 上传时间:2023-02-26
- 格式:DOCX
- 页数:11
- 大小:18.16KB
为什么说 Git 比 SVN 更好.docx
《为什么说 Git 比 SVN 更好.docx》由会员分享,可在线阅读,更多相关《为什么说 Git 比 SVN 更好.docx(11页珍藏版)》请在冰豆网上搜索。
为什么说Git比SVN更好
为什么说Git比SVN更好
H5App开发用WeX5,体验极速秒开!
?
在版本控制系统的选型上,是选择Git还是SVN?
对于开源项目来说这不算问题。
使用Git极大地提高了开发效率、扩大了开源项目的参与度、增强了版本控制系统的安全性,选择Git早已是大势所趋。
但对于企业用户来说这个决心不太好下。
部分原因是出于对Git的误解,部分原因是尚不了解Git到底能给项目管理带来什么好处。
希望本文能对您项目的版本控制系统选型提供帮助。
对SVN的迷信和对Git的误解
误解1:
SVN只能检出(checkout)一个版本(revision)的代码,而Git却可以脱库!
这个误解是如此普遍,简直成了SVN在企业市场中封杀Git的尚方宝剑。
其实稍微思考一下这个谣言就很难传播。
既然SVN能够读取授权访问的文件的每一个版本,那么就能够重组这些版本,进而实现对版本库的完整复制。
即SVN也可以脱库。
SVN脱库的工具SVN本身就提供:
svnsync。
这个工具主要用于SVN的版本库镜像。
例如将版本库http:
//host.name/svn/repo脱库到本地的dump目录,命令如下:
$svnadmincreatedump
$printf'#!
/bin/sh\nexit0\n'>dump/hooks/pre-revprop-change
$chmoda+xdump/hooks/pre-revprop-change
$svnsyncinitfile:
//$(pwd)/dumphttp:
//host.name/svn/repo
$svnsyncsyncfile:
//$(pwd)/dump
如果使用git-svn则为SVN“脱库”更简便。
$gitsvnclone-shttp:
//host.name/svn/repodump
有人认为SVN可以对目录授权,从而阻止对整个版本库进行脱库操作。
下面就来看看SVN的授权究竟是否可靠。
误解2:
SVN能对目录进行精细授权,而Git太不安全
SVN的目录授权对管理员来说是灾难,管理负担相当重,在分支或里程碑众多的时候很难作对。
这是因为SVN的分支和里程碑(tags)本身就是一个目录(使用目录拷贝实现的)。
例如管理员为名为demo的SVN版本库授权。
一个并不太复杂的主线(/trunk)授权如下:
[demo:
/trunk]
@demo-admin=rw
@leaders=r
[demo:
/trunk/doc]
@demo-dev=rw
@designers=rw
[demo:
/trunk/src/apps]
@demo-dev=rw
[demo:
/trunk/src/common]
@demo-dev=rw
[demo:
/trunk/src/html]
@designers=rw
[demo:
/trunk/src/secret]
*=
@demo-admin=rw
jiangxin=rw
如果项目创建了维护分支/branches/1.x,若和/trunk授权相同,则需要将上述授权在/branches/1.x下重建。
需要在授权文件中再添加如下授权指令:
[demo:
/branches/1.x]
@demo-admin=rw
@leaders=r
[demo:
/branches/1.x/doc]
@demo-dev=rw
@designers=rw
[demo:
/branches/1.x/src/apps]
@demo-dev=rw
[demo:
/branches/1.x/src/common]
@demo-dev=rw
[demo:
/branches/1.x/src/html]
@designers=rw
[demo:
/branches/1.x/src/secret]
*=
@demo-admin=rw
jiangxin=rw
如果版本库的分支和里程碑越来越多,配置的工作量相当可观,稍有不慎不是授权文件格式破坏导致SVN无法工作,就是造成开放授权。
我曾经写过SVN路径授权的补丁,并写了一款SVN版本库管理的开源软件(参见《pySvnManager手册》),但想完美解决这个问题很难。
我的一个设想是在SVN对分支和里程碑授权检查时缺省使用/trunk的授权,但这样的实现要求使用SVN严格遵循约定俗成的三个顶级目录的规范。
Git对于写操作可以精细到目录和分支级别(使用Gitolite作为服务器),但作为分布式版本库控制系统,在设计上只能实现版本库量子化的读授权。
即某用户对整个版本库要么都能读,要么对整个版本库都不能读。
那么如何控制Git版本库的读授权呢?
实际上Git可以通过子模组来实现细粒度的读授权。
即在项目需要精细授权的场合,将版本库拆分为多个Git版本库进行单独授权,再使用子模组将多个版本库整合为一个。
这个操作并不复杂,而且有助于实现项目的模块化。
误解3:
Git能随意改变历史提交,这对于版本控制来说是不合适的
Git对历史提交的修改只对本地提交有意义。
本地提交就像是和共享版本库间的缓冲。
在未将本地提交推送到远程共享版本库之前,开发者可以后悔。
可以对不完整的提交说明进行补充,可以移除错误的提交,可以压缩合并提交等。
Git对提交历史灵活的操作是Git独有的功能,是提交审核的必备工具。
对于已经推送到远程共享服务器的提交,Git就不能再像本地一样随意更改了。
因为推送到共享版本库的提交一旦被其他程序员获取,便扩散出去,如覆水难收,难掩众人悠悠之口。
所以Git更改历史提交只对本地有效,是安全的。
相比之下,SVN本地工作区和集中式版本库之间没有缓冲,一旦发现提交了错误内容,或写了错误的提交说明,则无法更改,除非SVN管理员介入。
SVN也允许配置为可修改历史提交说明,但是一旦管理员放开此功能,历史提交的提交说明有可能被批量、恶意更改,并且无法恢复。
误解4:
SVN对中文支持更好,Git库中的中文目录和文件名会出现乱码
我也曾经这么认为,并在《Git权威指南》第3章中用了大量篇幅介绍中文支持的注意事项。
并推荐使用Cygwin作为首选客户端,以避免GBK字符集为跨平台开发的版本库引入乱码。
一个好消息是Windows下最常用的Git客户端msysGit也支持Unicode了。
使用最新版本(1.7.10)的msysGit无需设置任何Git配置变量,版本库中的中文文件名、目录名、提交说明都使用Unicode编码。
配合使用Unicode版的TortoiseGit(最新的1.7.9.0版本已是Unicode版),Windows用户就不再为跨平台开发的字符集问题而伤脑筋了。
误解5:
SVN的认证方式比Git丰富,比如可以实现LDAP认证
我为客户配置的Git支持HTTP、SSH协议,和Gitweb。
其中HTTP协议、Gitweb都使用LDAP认证,实现统一的口令管理。
并且无论是HTTP协议、SSH协议,还是Gitweb都使用同一套Gitolite授权。
误解6:
SVN更易上手,更易管理;而Git太难和太灵活了,不适合团队?
如果想把配置管理做好,无论是SVN还是Git都不容易,否则《SVNBook》以及我写《Git权威指南》也不会有那么厚了。
觉得SVN更简单的,看看下面的错误你有没有犯?
很多公司的SVN版本库没有遵照约定俗成的三个顶级目录。
如何配置SVN悲观锁,以便更好地对二进制文件编辑进行协同。
维护合并追踪的svn:
mergeinfo属性,以便能够正确的分支合并。
还要防止无此功能的客户端对其的破坏。
SVN如何正确的反删除,直接添加删除的文件是不对的。
如何使用svn:
eol-style属性,以便正确处理跨平台开发时的文件换行符问题。
SVN管理员如何对版本库进行整理,如撤出不当提交、修改错误的提交说明。
版本库的安全性问题,如何做好版本库的备份。
SVN对分支当做路径来授权,造成管理的负担(参见前面的描述),因此使用SVN实现灵活的特性分支开发、可靠的发布控制(维护分支冻结)很难。
企业应用Git的困惑之一是如何裁剪出适合自己的工作流。
实际上Git本身已经给出范例:
$githelpworkflows
理解Git的应用模型并选用合适的服务器端软件(如Gitolite),可以定制出适合自己的工作流。
例如下表就是在企业中使用Git版本控制系统的典型角色划分:
系统管理员配置管理员发布工程师整合工程师模块负责人开发工程师
(SYSadm)
(SCMadm)
(RELeng)
(INTegrator)
(MODmaster)
(DEV)
创建版本库
?
版本库授权
?
版本库改名
?
?
删除版本库
?
?
创建Tag
?
删除Tag
?
创建一级分支
?
为分支授权
?
向maint分支强推
?
向master分支强推
?
向maint分支写入
?
向master分支写入
?
?
创建个人专有分支
?
?
?
?
?
创建个人专有版本库
?
?
?
?
?
为个人专有版本库授权
?
?
?
?
?
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 为什么说 Git SVN 更好 为什么