集中式

类似于集中式版本控制系统(CVCS),Git集中式工作流程使用的也是单点协作模型:一个存放代码仓库的中心服务器,可以接受所有开发者提交的代码.

Alt
集中式工作流
如果两个开发者从中心仓库克隆代码下来,同时作了一些修订,那么只有第一个开发者可以顺利地把数据推送到共享服务器。第二个开发者在提交他的修订之前,必须先下载合并服务器上的数据,解决冲突之后才能推送数据到共享服务器上。

集中管理员工作流

由于Git允许使用多个远程仓库，开发者便可以建立自己的公共仓库，往里面写数据并共享给他人，而同时又可以从别人的仓库中提取他们的更新过来。这种情形通常都会有个代表着官方发布的项目仓库（blessed repository,开发者们由此仓库克隆出一个自己的公共仓库（developer public），然后将自己的提交推送上去，请求官方仓库的维护者拉取更新合并到主项目。维护者在自己的本地也有个克隆仓库（integration manager），他可以将你的公共仓库作为远程仓库添加进来，经过测试无误后合并到主干分支，然后再推送到官方仓库。

Alt
集中管理员工作流

整个工作流程如下:

  1. 项目维护者可以推送数据到公共仓库 blessed repository。
  2. 贡献者克隆此仓库，修订或编写新代码。
  3. 贡献者推送数据到自己的公共仓库 developer public。
  4. 贡献者给维护者发送邮件，请求拉取自己的最新修订。
  5. 维护者在自己本地的 integration manger 仓库中，将贡献者的仓库加为远程仓库，合并更新并做测试。
  6. 维护者将合并后的更新推送到主仓库 blessed repository。

发现了没,托管服务中的fork和push request就是这种工作流.

司令官与副官工作流

一般只有超大型项目才会用到这个工作流.其实是集中管理员工作流的变体,各个集成管理员分别负责集成项目中的特定部分，所以称为副官(lieutenant).而所有这些集成管理员头上还有一位负责统筹的总集成管理员，称为司令官(dictator) 司令官维护的仓库用于提供所有协作者拉取最新集成的项目代码。

Alt
集中管理员工作流

整个工作流程如下:

  1. 一般的开发者在自己的特性分支上工作，并不定期地根据主干分支（dictator 上的 master）衍合。
  2. 副官（lieutenant）将普通开发者的特性分支合并到自己的 master 分支中。
  3. 司令官（dictator）将所有副官的 master 分支并入自己的 master 分支。
  4. 司令官（dictator）将集成后的 master 分支推送到共享仓库 blessed repository 中，以便所有其他开发者以此为基础进行衍合

这种工作流并不常用,只有当项目庞杂需要更多级别管理时才有优势.

实例

可以参考原书的为项目作贡献