Skip to content

Commit ef846ba

Browse files
committed
Add git workflows in why-git-is-better-than-svn
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
1 parent a93aa0d commit ef846ba

File tree

1 file changed

+51
-14
lines changed

1 file changed

+51
-14
lines changed

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

Lines changed: 51 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -35,6 +35,8 @@ SVN脱库的工具SVN本身就提供: ``svnsync`` 。这个工具主要用于S
3535
有人认为SVN可以对目录授权,从而阻止对整个版本库进行脱库操作。
3636
下面就来看看SVN的授权究竟是否可靠。
3737

38+
<a name='svnauthz' id='svnauthz'></a>
39+
3840
### 误解2:SVN能对目录进行精细授权,而Git太不安全 ###
3941

4042
SVN的目录授权对管理员来说是灾难,管理负担相当重,在分支或里程碑众多的时候很难作对。
@@ -45,20 +47,20 @@ SVN的目录授权对管理员来说是灾难,管理负担相当重,在分
4547
[demo:/trunk]
4648
@demo-admin = rw
4749
@leaders = r
48-
50+
4951
[demo:/trunk/doc]
5052
@demo-dev = rw
5153
@designers = rw
52-
54+
5355
[demo:/trunk/src/apps]
5456
@demo-dev = rw
55-
57+
5658
[demo:/trunk/src/common]
5759
@demo-dev = rw
58-
60+
5961
[demo:/trunk/src/html]
6062
@designers = rw
61-
63+
6264
[demo:/trunk/src/secret]
6365
* =
6466
@demo-admin = rw
@@ -70,20 +72,20 @@ SVN的目录授权对管理员来说是灾难,管理负担相当重,在分
7072
[demo:/branches/1.x]
7173
@demo-admin = rw
7274
@leaders = r
73-
75+
7476
[demo:/branches/1.x/doc]
7577
@demo-dev = rw
7678
@designers = rw
77-
79+
7880
[demo:/branches/1.x/src/apps]
7981
@demo-dev = rw
80-
82+
8183
[demo:/branches/1.x/src/common]
8284
@demo-dev = rw
83-
85+
8486
[demo:/branches/1.x/src/html]
8587
@designers = rw
86-
88+
8789
[demo:/branches/1.x/src/secret]
8890
* =
8991
@demo-admin = rw
@@ -136,9 +138,14 @@ SVN也允许配置为可修改历史提交说明,但是一旦管理员放开
136138
我为客户配置的Git支持HTTP、SSH协议,和Gitweb。其中HTTP协议、Gitweb都使用LDAP认证,
137139
实现统一的口令管理。并且无论是HTTP协议、SSH协议,还是Gitweb都使用同一套Gitolite授权。
138140

139-
### 误解6:SVN更易上手,Git太难了 ###
141+
<a name='workflow' id='workflow'></a>
142+
143+
### 误解6:SVN更易上手,更易管理;而Git太难和太灵活了,不适合团队? ###
144+
145+
如果想把配置管理做好,无论是 SVN 还是 Git 都不容易,否则 [《SVN Book》](http://svnbook.red-bean.com/)
146+
以及我写 [《Git权威指南》](http://gotgit.github.com/gotgit/) 也不会有那么厚了。
140147

141-
如果想把配置管理做好,SVN并不容易,否则 [《SVN Book》](http://svnbook.red-bean.com/) 也不会有那么厚了。
148+
觉得SVN更简单的,看看下面的错误你有没有犯?
142149

143150
* 很多公司的SVN版本库没有遵照约定俗成的三个顶级目录。
144151
* 如何配置SVN悲观锁,以便更好地对二进制文件编辑进行协同。
@@ -148,7 +155,37 @@ SVN也允许配置为可修改历史提交说明,但是一旦管理员放开
148155
* SVN管理员如何对版本库进行整理,如撤出不当提交、修改错误的提交说明。
149156
* 版本库的安全性问题,如何做好版本库的备份。
150157

151-
Git的设计模型非常简单,理解了其设计思想,就可以很容易地掌握 ``git reset``,
158+
SVN对分支当做路径来授权,造成管理的负担(参见 [前面的描述](#svnauthz) ),
159+
因此使用SVN实现灵活的特性分支开发、可靠的发布控制(维护分支冻结)很难。
160+
161+
企业应用Git的困惑之一是如何裁剪出适合自己的工作流。实际上Git本身已经给出范例:
162+
163+
$ git help workflows
164+
165+
理解Git的应用模型并选用合适的服务器端软件(如 Gitolite),可以定制出适合自己的工作流。
166+
例如下表就是在企业中使用Git版本控制系统的典型角色划分:
167+
168+
169+
| | 系统管理员 | 配置管理员 | 发布工程师 | 整合工程师 | 模块负责人 | 开发工程师
170+
|---------------------------------|:-----------------------:|:----------:|:------------:|:------------:|:----------:
171+
| | (SYSadm) | (SCMadm) | (RELeng) | (INTegrator) | (MODmaster) | (DEV)
172+
| 创建版本库 | || | | |
173+
| 版本库授权 | || | | |
174+
| 版本库改名 || ? | | | |
175+
| 删除版本库 || ? | | | |
176+
| 创建Tag | | || | |
177+
| 删除Tag | || | | |
178+
| 创建一级分支 | || | | |
179+
| 为分支授权 | || | | |
180+
| 向 maint 分支强推 | || | | |
181+
| 向 master 分支强推 | || | | |
182+
| 向 maint 分支写入 | | || | |
183+
| 向 master 分支写入 | | | |||
184+
| 创建个人专有分支 | | ✔ | ✔ | ✔ | ✔ | ✔
185+
| 创建个人专有版本库 | | ✔ | ✔ | ✔ | ✔ | ✔
186+
| 为个人专有版本库授权 | | ✔ | ✔ | ✔ | ✔ | ✔
187+
188+
再来谈谈Git的使用,实际上Git的设计模型非常简单,理解了其设计思想,就可以很容易地掌握 ``git reset``,
152189
``git checkout``, ``git rebase``, ``git push``, ``git pull`` 等命令。
153190

154191
### 误解7:程序员不喜欢命令行 ###
@@ -210,7 +247,7 @@ Git的基于DAG(有向非环图)的设计比SVN的线性提交提供更好
210247
提交没有合并到最新版本而造成已修复问题在新版本中重现。
211248

212249
Git分支和合并追踪可以解决这个问题。例如用 maint 分支跟踪最新的发行版,
213-
当确定里程碑tag v1.6.4 为最新发行版时,在 maint
250+
当确定里程碑tag v1.6.4 为最新发行版时,在 maint
214251
分支执行如下命令以切换到最新发行版:
215252

216253
$ git checkout maint

0 commit comments

Comments
 (0)