Pro Git摘要
《Pro Git》是Git官方的电子书，在“分布式 Git”这一章专门讲
解了Git的团队协作流程涉及的方方面面。
分布式工作流程
集中式工作流 -- 有一个中心仓库，所有人将自己的工作与之同
步。这和 Subversion （或任何 CVCS）中的概念一样。
集成管理者工作流 -- 主管（集成管理者）和每个开发者都拥有
自己的一个公开仓库和私有仓库。主管的公开仓库就是代表官方
的权威仓库。这是在GitHub等Git托管站点最常用的工作流程。
主管与副主管工作流 -- 被称为 副主管（lieutenant） 的各
个集成管理者分别负责集成项目中的特定部分。 之上还有一位
称为 主管（dictator） 的总集成管理者负责统筹。这种工作
流程并不常用，只有当项目极为庞杂，或者需要多级别管理时，
才会体现出优势。
向一个项目贡献
本节描述了不同团队规模下开发者角色的工作示例。这里“私有”意
味着闭源。
私有小型团队 -- 开发者都有仓库的推送权限。在这个环境下，
可以采用一个类似使用 Subversion 或其他集中式的系统时会
使用的工作流程。
私有管理团队 -- 多个小组分别负责不同的主题分支，小组长将
组员的主题分支整合到该组的主题分支，管理者将所有小组的主
题分支整合到主仓库的 master 分支。Git托管站点的公开项目 -- 开发者在Git托管站点上Fork创建
一份自己的公开仓库，在本地克隆一份私有仓库，为计划贡献的
补丁或补丁序列创建一个主题分支，然后在那儿做工作。开发者
完成工作后推送到自己的公开仓库的主题分支，在托管站点创建
一个拉取请求（Pull Request, 建成PR）从自己公开仓库的主
题分支到主仓库。
通过邮件的公开项目 -- 有几个历史悠久的、大型的项目会通过
一个开发者的邮件列表接受补丁。在Git托管站点流行之后，这
种协作方式变得罕见。
维护项目
描述了管理者如何整合开发者的PR。
在主题分支中工作 -- 为要整合的若干有关联的PR创建主题分支，
它是一种通常用来尝试新东西的临时分支。这样便于单独调整补
丁，如果遇到无法正常工作的情况，可以先不用管，等到有时间的
时候再来处理。
合并工作流
一种基本的工作流就是将所有的工作直接合并到 master 分支。
在这种情况下，master 分支包含的代码是基本稳定的。 当你完
成某个主题分支的工作，或审核通过了其他人所贡献的工作时，你
会将其合并进入 master分支，之后将主题分支删除，如此反复。
当项目更大，或更稳定，你可能会使用两阶段合并循环。在这种情
况下，你会维护两个长期分支，分别是master 和 develop，
master 分支只会在一个非常稳定的版本发布时才会更新，而所有
的新代码会首先整合进入 develop 分支。 你定期将这两个分支
推送到公共版本库中。 每次需要合并新的主题分支时（合并主题分
支前），你都应该合并进入 develop 分支（合并主题分支后）；
当打标签发布的时候，你会将 master 分支快进到已经稳定的
develop 分支（一次发布之后）。
