在使用集中式版本控制工具时，使用的就是集中式工作流，所有的开发人员共享一个代码仓库，当其中一人提交代码时需要先更新其它人的提交，可能会出现代码冲突需要合并，还有可能会将其它人的提交覆盖掉，同时由于无法保证代码质量，甚至会出现引入了其它开发人员的代码导致编译不通过、测试不通过等等问题，所以在使用集中式工作流程的时候最不能缺少的就是“沟通”。
对于开源项目来说开发人员来自全世界，其沟通成本远远大于本地团队，那么作为开源项目使用最广泛的版本控制工具，它是如何解决协同开发问题？
Git中可以创建多个仓库，集成管理者工作流的核心就是项目的主仓库由“集成者”负责，其它开发人员拥有自己的仓库，开发者把完成的工作提交到自己的公开库中，然后“集成者”从这些公开库中拉取代码，最终合并到主仓库中，如下图：
这样做有以下几个好处：
开发人员有自己的代码库，减少了更新、合并等操作(注：更新、合并的根源在于不同开发任务之间的依赖，如果依赖严重，那么更新、合并是不可避免的，最理想的情况是没有依赖，那么开发人员只需完成自己的工作提交即可)。
所有代码合并由“集成者”完成合并，而一般“集成者”由经验丰富的程序员担任，代码合并的过程强制进行了代码复审，对于代码的质量是可控的，有效保证主项目代码的干净整洁。
由于代码的复审，开发人员在提交代码时也不会太随意，变相提高了代码质量。
但是相对于集中式的工作流来说由于需要等待合并，提交工作也比较复杂，所以开发效率会相对降低。
司令官与副官工作流司令官与副官工作流是集成管理者工作流的拓展，引入了多级“集成者”来完成多级的代码合并操作，该模式适用于复杂的多级管理的项目开发：
更多关于Git分布式工作流的内容可参考：https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows
Pull Request 在Git中无论是集中式工作流还是集成管理者工作流，它都有一个核心的操作就是合并代码，对于集中式工作流来说，当分支完成开发后，需要将代码进行合并，一般是将分支代码合并到远程的如Master或Develop之类的长期分支上，其流程如下：
1. 创建一个功能分支feature1(git checkout -b feature1)。
2. 在分支上完成功能并提交(git add & git commit)。
3. 切换到master分支执行合并操作，并将更新推到远程仓库(git checkout master, git merge feature1, git push)。
4. 删除特性分支(git branch -d feature1)。
过程如下图所示：
但是对于集成管理者工作流来说，集成管理者要如何知道有代码需要合并？要如何合并代码？Git中引入了pull request这一功能彻底的改变了代码的合并方式，这一特性也让其成为开源专用的版本控制工具。
pull request是什么？用中文翻译过来是“拉请求”，假设以下场景：
1. Selim开发了一个应用程序My Blog，并通过某一Git远程托管平台对代码进行了托管。
2. 7m鱼复制了Selim托管的库，然后在App上添加了一个新功能feature1。
3. 现在7m鱼想要将新功能合并到Selim的分支上应该如何操作？如下图所示：
首先可以想到的就是使用上面提到的方法切换到Selim的master分支，然后执行git merge Feature1命令，但是如果7m鱼没有Selim/Master的修改权限呢？Selim/Master是属于Selim的，7m鱼无法修改(典型的集成管理者模式，这里“Selim”就是集成管理者)，为了解决这个问题Git实现了“Pull Request(拉请求)”，注意是“拉(pull)”不是“推(push)”，这个请求的目的是让仓库所有者来“拉”取变化，由所有者来决定合并还是拒绝，所有者可以根据功能是否合理、代码是否正确、易读等信息进行判断，这实际上就是CodeRview的过程。
下面创建一个新的代码仓库来演示Git的Pull Request，Pull Request的要求就是需要两个远程分支(仓库)进行合并(代码拥有者的分支和代码贡献者的分支)：
1. 克隆My Blog代码，创建一个新的远程仓库(本例使用GitHub作为托管平台，可以直接fork)：
git clone https://github.com/yqszt/MyBlog.git
git remote add other https://github.com/SelimTeam/MyBlog.git
git push -u other
新建的远程仓库：
2. 在克隆的代码中修改内容并提交：
