why-git-is-better: review and add repo security

jiangxin · jiangxin · commit a93aa0d334f4 · 2012-04-13T08:29:28.000+08:00
Signed-off-by: Jiang Xin &lt;worldhello.net@gmail.com&gt;
diff --git a/_posts/2012-04-12-why-git-is-better-than-svn.md b/_posts/2012-04-12-why-git-is-better-than-svn.md
@@ -89,25 +89,25 @@ SVN的目录授权对管理员来说是灾难，管理负担相当重，在分
     @demo-admin = rw
     jiangxin = rw
 
-如果版本库的分支和里程碑越来越多，配置的工作量相当客观，稍有不慎不是授权文件格式破坏，
+如果版本库的分支和里程碑越来越多，配置的工作量相当可观，稍有不慎不是授权文件格式破坏导致SVN无法工作，
 就是造成开放授权。
 
 我曾经写过SVN路径授权的补丁，并写了一款SVN版本库管理的开源软件
 （参见 [《pySvnManager手册》](http://www.ossxp.com/doc/pysvnmanager/user-guide/user-guide.html) ），
-但想完美解决这个问题很难。我的一个设想是在SVN对分支和里程碑授权检查时的缺省检查
-``/trunk`` 的授权，但这样的实现要求使用SVN严格遵循约定俗成的三个顶级分支的规范。
+但想完美解决这个问题很难。我的一个设想是在SVN对分支和里程碑授权检查时缺省使用
+``/trunk`` 的授权，但这样的实现要求使用SVN严格遵循约定俗成的三个顶级目录的规范。
 
 Git对于写操作可以精细到目录和分支级别（使用Gitolite作为服务器），
 但作为分布式版本库控制系统，在设计上只能实现版本库量子化的读授权。
 即某用户对整个版本库要么都能读，要么对整个版本库都不能读。
 
-Git通过子模组来实现细粒度的读授权。即在项目需要精细授权的场合，
-采用将版本库拆分为多个Git版本库进行单独授权，再使用子模组将多个版本库整合为一个。
-这个操作并不复杂，而且有助于实现项目的模块化。
+那么如何控制Git版本库的读授权呢？实际上Git可以通过子模组来实现细粒度的读授权。
+即在项目需要精细授权的场合，将版本库拆分为多个Git版本库进行单独授权，
+再使用子模组将多个版本库整合为一个。这个操作并不复杂，而且有助于实现项目的模块化。
 
 ### 误解3：Git能随意改变历史提交，这对于版本控制来说是不合适的 ###
 
-Git对历史提交的修改只对本地提交有意义。本地提交就像是本地版本库和共享版本库间的缓冲。
+Git对历史提交的修改只对本地提交有意义。本地提交就像是和共享版本库间的缓冲。
 在未将本地提交推送到远程共享版本库之前，开发者可以后悔。可以对不完整的提交说明进行补充，
 可以移除错误的提交，可以压缩合并提交等。Git对提交历史灵活的操作是Git独有的功能，
 是提交审核的必备工具。
@@ -124,26 +124,29 @@ SVN也允许配置为可修改历史提交说明，但是一旦管理员放开
 ### 误解4：SVN对中文支持更好，Git库中的中文目录和文件名会出现乱码 ###
 
 我也曾经这么认为，并在《Git权威指南》第3章中用了大量篇幅介绍中文支持的注意事项。
-一个好消息是最新版本（1.7.10）的 msysGit 已经支持Unicode，
-即中文的文件名、目录名、提交说明使用Unicode编码保存在版本库中。
-Windows用户配合使用Unicode版的TortoiseGit，
-就不再为跨平台开发的字符集问题而伤脑筋了。
+并推荐使用Cygwin作为首选客户端，以避免GBK字符集为跨平台开发的版本库引入乱码。
 
-### 误解5：SVN的认证配置比Git简单，比如可以实现LDAP认证 ###
+一个好消息是Windows下最常用的Git客户端 msysGit 也支持Unicode了。
+使用最新版本（1.7.10）的 msysGit 无需设置任何Git配置变量，
+版本库中的中文文件名、目录名、提交说明都使用Unicode编码。
+配合使用Unicode版的TortoiseGit，Windows用户就不再为跨平台开发的字符集问题而伤脑筋了。
 
-我为客户配置的Git支持HTTP和SSH协议及Gitweb，其中HTTP协议和Gitweb都使用LDAP认证，实现统一的口令管理。
-并且无论是HTTP协议、SSH协议还是Gitweb都使用同一套Gitolite授权。
+### 误解5：SVN的认证方式比Git丰富，比如可以实现LDAP认证 ###
+
+我为客户配置的Git支持HTTP、SSH协议，和Gitweb。其中HTTP协议、Gitweb都使用LDAP认证，
+实现统一的口令管理。并且无论是HTTP协议、SSH协议，还是Gitweb都使用同一套Gitolite授权。
 
 ### 误解6：SVN更易上手，Git太难了 ###
 
 如果想把配置管理做好，SVN并不容易，否则 [《SVN Book》](http://svnbook.red-bean.com/) 也不会有那么厚了。
 
 * 很多公司的SVN版本库没有遵照约定俗成的三个顶级目录。
-* 配置SVN悲观锁，以便更好地对二进制文件编辑进行协同。
+* 如何配置SVN悲观锁，以便更好地对二进制文件编辑进行协同。
 * 维护合并追踪的 svn:mergeinfo 属性，以便能够正确的分支合并。还要防止无此功能的客户端对其的破坏。
 * SVN如何正确的反删除，直接添加删除的文件是不对的。
 * 如何使用 svn:eol-style 属性，以便正确处理跨平台开发时的文件换行符问题。
-* SVN管理员如何对版本库进行整理，及如何做好版本库的备份。
+* SVN管理员如何对版本库进行整理，如撤出不当提交、修改错误的提交说明。
+* 版本库的安全性问题，如何做好版本库的备份。
 
 Git的设计模型非常简单，理解了其设计思想，就可以很容易地掌握 ``git reset``,
 ``git checkout``, ``git rebase``, ``git push``, ``git pull`` 等命令。
@@ -178,8 +181,8 @@ Git可以很容易地对比两个分支，知道一个分支中哪些提交尚
 针对同一个项目，Git可以设置不同层级的版本库（多版本库），
 或者通过不同的分支（多分支）实现对发布的控制。
 
-即设置只有发布管理员才有权限推送的用于稳定版本发布的版本库或者分支，
-设置只有项目经理才有权推送的用于整合测试的版本库或分支，以实现对产品发布的控制。
+* 设置只有发布管理员才有权限推送的版本库或者分支，用于稳定发布版本的维护。
+* 设置只有项目经理、模块管理员才有权推送的版本库或者分支，用用于整合测试。
 
 ### 隔离开发，提交审核 ###
 
@@ -190,12 +193,17 @@ Git可以很容易地对比两个分支，知道一个分支中哪些提交尚
 审核新成员提交时，从其个人版本库或个人分支获取（fetch）提交，从提交说明、代码规范、编译测试
 等多方面对提交逐一审核。审核通过执行 ``git merge`` 命令合并到开发主线中。
 
-### 更少的冲突，更好的冲突解决 ###
+### 对合并更好的支持，更少的冲突，更好的冲突解决 ###
 
 因为Git基于对内容的追踪而非对文件名追踪，所以遇到一方或双方对文件名更改时，
-Git能够很好进行自动合并，而SVN面则会遇到树冲突，解决起来很麻烦。
+Git能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突，
+解决起来很麻烦。
+
+Git的基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪，
+避免不必要的冲突，提高工作效率。这是开发者选择Git、抛弃SVN的重要理由。
 
-### 更好的合并追踪，以保证已修复Bug不再重现 ###
+
+### 保证已修复Bug不再重现 ###
 
 以为创建完毕里程碑标签（tag）便完成软件版本的发布是有风险的，
 往往会由于之前的版本（维护版本）中的一些 Hotfix
@@ -211,6 +219,18 @@ Git分支和合并追踪可以解决这个问题。例如用 maint 分支跟踪
 如果合并成功，代表发行版 v1.6.4 包含了所有前一个发行版的提交。
 反之说明前一个发行版某个或某些Hotfix提交尚未合并到最新发行版中。
 
+### 版本库的安全性 ###
+
+SVN版本库安全性很差，是管理员头痛的问题。
+
+* SVN版本库服务器端历史数据被篡改，或者硬盘故障导致历史数据被篡改时，
+  客户端很难发现。管理员的备份也会被污染。
+* SVN作为集中式版本控制系统，存在单点故障的风险。备份版本库的任务非常繁重。
+
+Git在这方面完胜SVN。首先Git是分布式版本控制系统，每个用户都相当于一份备份，
+管理员无需为数据备份而担心。再有Git中包括提交、文件内容等都通过SHA1哈希保证数据的完整性，
+任何恶意篡改历史数据都会被及时发现从而被挫败。
+
 ### 更多的十条喜欢Git的理由 ###
 
 更多的十条喜欢Git的理由，参见 [《Git权威指南》](http://www.worldhello.net/gotgit/) 第11-21页。
