4. 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完美的协同工作。
目录:
- 4.1. 经典Git协同模型
- 4.2. 金字塔式协同模型
- 4.3. Topgit协同模型
- 4.3.1. 作者版本控制系统三个里程碑
- 4.3.2. Topgit原理
- 4.3.3. Topgit的安装
- 4.3.4. Topgit的使用
- 4.3.4.1. tg help命令
- 4.3.4.2. tg create命令
- 4.3.4.3. tg info命令
- 4.3.4.4. tg update命令
- 4.3.4.5. tg summary命令
- 4.3.4.6. tg remote命令
- 4.3.4.7. tg push命令
- 4.3.4.8. tg depend命令
- 4.3.4.9. tg base命令
- 4.3.4.10. tg delete命令
- 4.3.4.11. tg patch命令
- 4.3.4.12. tg export命令
- 4.3.4.13. tg import命令
- 4.3.4.14. tg log命令
- 4.3.4.15. tg mail命令
- 4.3.4.16. tg graph命令
- 4.3.5. Topgit hacks
- 4.3.6. Topgit使用中的注意事项
- 4.4. 子模组协同模型
- 4.5. 子树合并
- 4.6. Android式多版本库协同
- 4.6.1. 关于repo
- 4.6.2. 安装repo
- 4.6.3. repo和清单库的初始化
- 4.6.4. 清单库和清单文件
- 4.6.5. 同步项目
- 4.6.6. 建立Android代码库本地镜像
- 4.6.7. Repo的命令集
- 4.6.7.1. repo init命令
- 4.6.7.2. repo sync命令
- 4.6.7.3. repo start命令
- 4.6.7.4. repo status命令
- 4.6.7.5. repo checkout命令
- 4.6.7.6. repo branches命令
- 4.6.7.7. repo diff命令
- 4.6.7.8. repo stage命令
- 4.6.7.9. repo upload命令
- 4.6.7.10. repo download命令
- 4.6.7.11. repo rebase命令
- 4.6.7.12. repo prune命令
- 4.6.7.13. repo abandon命令
- 4.6.7.14. 其他命令
- 4.6.8. Repo命令的工作流
- 4.6.9. 好东西不能Android独享
- 4.7. Git和SVN协同模型