Git协同模型
#####################

分布式的版本控制会不会造成开发中的无序，导致版本管理的崩溃？对于习惯了如\
Subversion这类的集中式版本控制系统的用户，脑子里一定会有这个疑问。

作为分布式版本控制系统，每一个Git克隆都是一个完整的版本库，可以提供一个\
版本控制服务器所能提供的一切服务，即每个人的机器都是一台服务器。与之相反，\
像Subversion那样的集中式版本控制系统，只拥有唯一的版本控制服务器，所有\
团队成员都使用客户端与之交互，大部分操作要通过网络传输来实现。对于习惯了\
和唯一服务器交互的团队，转换到Git后，该如何协同团队的工作呢？在第21章\
“经典Git协同模型”中会介绍集中式和金字塔式两种主要的协同工作模型。

基于某个项目进行二次开发，需要使用不同的工作模型。原始的项目称为上游项目，\
不能直接在上游项目中提交，可能是因为授权的原因或者是因为目标用户的需求\
不同。这种基于上游项目进行二次开发，实际上是对各个独特的功能分支进行管理，\
同时又能对上游项目的开发进度进行兼收并蓄式的合并。第22章“Topgit协同模型”\
会重点介绍这一方面的内容。

多个版本库组成一个项目，在实际应用中并不罕见。一部分原因可能是版本库需要\
依赖第三方的版本库，这时第23章介绍的“子模组协同模型”就可以派上用场。有的\
时候还要对第三方的版本库进行定制，第24章“子树合并”提供了一个解决方案。有\
的时候，为了管理方便（授权或者项目确实太庞杂），多个版本库共同组成一个大\
的项目，例如Google Android项目就是由近200个版本库组成的。第25章\
“Android式多版本库协同”提供了一个非常有趣的解决方案，解决了“子模组协同模型”\
的管理上的难题。

在本篇的最后（第26章），会介绍git-svn这一工具。可能因为公司对代码严格的\
授权要求，而不能将公司的版本控制服务器从Subversion迁移到Git（实际可以通\
过对Git版本库细粒度拆分实现授权管理），可是这并不能阻止个人使用git-svn作\
为前端工具操作Subversion版本库。git-svn可以让Git和Subversion完美的协同工作。


目录:

.. toctree::
   :maxdepth: 3

   010-central-model
   020-distribute-model
   030-topgit-model
   040-submodule-model
   050-subtree-model
   060-android-model
   070-git-svn