上一个主题

3.6. 补丁文件交互

下一个主题

4.1. 经典Git协同模型

本页

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完美的协同工作。

目录: