分布式Git
分布式工作流程
同传统的集中式版本控制系统（CVCS）不同，开发者之间的协作方式因着Git 的分布式
特性而变得更为灵活多样。在集中式系统上，每个开发者就像是连接在集线器上的节点，彼
此的工作方式大体相像。而在Git 网络中，每个开发者同时扮演着节点和集线器的角色，
这就是说，每一个开发者都可以将自己的代码贡献到另外一个开发者的仓库中，或者建立自
己的公共仓库，让其他开发者基于自己的工作开始，为自己的仓库贡献代码。于是，Git 的
分布式协作便可以衍生出种种不同的工作流程
集中式工作流
集中式工作流程使用的都是单点协作模型。一个存放代码仓库的中心服务器，可以接受所有开发者提交的代码。所有的开发者都是普通的节点，作为中心集线器的消费者，平时的工作就是和中心仓库同步数据
如果两个开发者从中心仓库克隆代码下来，同时作了一些修订，那么只有第一个开发者可
以顺利地把数据推送到共享服务器。第二个开发者在提交他的修订之前，必须先下载合并
服务器上的数据，解决冲突之后才能推送数据到共享服务器上。在Git 中这么用也决无问
题，这就好比是在用Subversion（或其他CVCS）一样，可以很好地工作。
集成管理员工作流
由于Git 允许使用多个远程仓库，开发者便可以建立自己的公共仓库，往里面写数据并
共享给他人，而同时又可以从别人的仓库中提取他们的更新过来。这种情形通常都会有个代
表着官方发布的项目仓库（blessed repository），开发者们由此仓库克隆出一个自己的公
共仓库（developer public），然后将自己的提交推送上去，请求官方仓库的维护者拉取更
新合并到主项目。维护者在自己的本地也有个克隆仓库（integration manager），他可以
将你的公共仓库作为远程仓库添加进来，经过测试无误后合并到主干分支，然后再推送到官
方仓库。
1. 项目维护者可以推送数据到公共仓库blessed repository。
2. 贡献者克隆此仓库，修订或编写新代码。
3. 贡献者推送数据到自己的公共仓库developer public。
4. 贡献者给维护者发送邮件，请求拉取自己的最新修订。
5. 维护者在自己本地的integration manger 仓库中，将贡献者的仓库加为远程仓库，
合并更新并做测试。
6. 维护者将合并后的更新推送到主仓库blessed repository。
司令官与副官工作流
各个集成管理员分别负责集成项目中的特定部分，所以称为副官（lieutenant）。而所有这些集成管理员头上还有一位负责统筹的总集成管理员，称为司令官（dictator）。司令官维护的仓库用于提供所有协作者拉取最新集成的项目代码。整个流程：
1. 一般的开发者在自己的特性分支上工作，并不定期地根据主干分支（dectator 上的
master）衍合。
2. 副官（lieutenant）将普通开发者的特性分支合并到自己的master 分支中。
3. 司令官（dictator）将所有副官的master 分支并入自己的master 分支。
4. 司令官（dictator）将集成后的master 分支推送到共享仓库blessed repository
中，以便所有其他开发者以此为基础进行衍合。
提交指南
首先，请不要在更新中提交多余的白字符（whitespace）。Git 有种检查此类问题的方
法，在提交之前，先运行git diff --check，会把可能的多余白字符修正列出来。
接下来，请将每次提交限定于完成一次逻辑功能。并且可能的话，适当地分解为多次小更
新，以便每次小型提交都更易于理解。
最后需要谨记的是提交说明的撰写。