21.2　金字塔式协同模型

自从分布式版本库控制系统（Mercurial/Hg、Bazaar、Git等）诞生之后，有越来越多的开源项目迁移了版本控制系统，例如从Subversion或CVS迁移到分布式版本控制系统。因为众多的开源项目逐渐认识到，集中式的版本控制管理方式阻止了更多的人参与项目的开发，对项目的发展不利。

集中式版本控制系统的最大问题是，如果没有在服务器端授权，就无法提交，也就无法保存自己的更改。开源项目虽然允许所有人访问代码库，但是不可能授权“写操作”给所有的人，否则代码质量无法控制（Gerrit审核服务器是例外）。与此相对照的是，在使用了分布式版本控制系统之后，任何人都可以在本地克隆一个和远程版本库一模一样的版本库，本地的版本库允许任何操作，这就极大地调动了开发者投入项目研究的积极性。

分布式的开发必然带来协同的问题，如何能够让一个素不相识的开发者将他的贡献提交到项目中？如何能够最大化地发动和汇聚全球的智慧？开源社区逐渐发展出金字塔模型（如图21-4所示），而这也是必然之选。

金字塔模型的含义是，虽然理论上每个开发者的版本库都是平等的，但是会有一个公认的权威的版本库，这个版本库由一个或多个核心开发者负责维护（具有推送的权限）。核心的开发人员负责审核其他贡献者的提交，审核可以通过邮件传递的补丁或访问（PULL）贡献者开放的代码库进行。由此构成了以核心开发团队为顶层的、所有贡献者共同参与的开发

21.2.1　贡献者开放只读版本库

$git checkout-b jiangxin/fix-bug-xxx origin/master

$git config branch.jiangxin/fix-bug-xxx.rebase true

hack,hack,hack

$git pull

然后贡献者就可以向项目管理者发送通知邮件，告诉项目管理者有新贡献的代码等待他的审核。邮件中大致包括以下内容：

为什么要修改项目的代码。

相应的修改是否经过了测试，或者提交中是否包含了单元测试。

自己版本库的访问地址。

特性分支的名称。

Git提供了一个名为git request-pull的命令，可以非常方便地生成上述信息。