注意：作者说发送过Pull Request，就会得到仓库的管理权，是扯淡的，肯定有专人维护！！所以采纳Pull Request 的方法，看看即可。

一、采纳 Pull Request 的方法

（1）接收到 Pull Request 后，会如图 7.1 中所示

（2）点击 Mergepull request 按钮（图 7.2）， Pull Request 的内容便会自动合并至仓库。
在采纳之前，用将要在第 8 章中介绍的 Jenkins 等持续集成工具进行自动测试， 保证新代码不破坏原有功能之后，再合并进仓库

二、本地开发环境中检查接收到的 Pull Request的流程。

1.代码审查

（1）学会使用各种各样的功能进行代码审查，要比以往使用工具的审查轻松很多。
如图 7.3 所示，在 GitHub 上可以对 Pull Request 的具体的某行代码
进行评论。这让代码审查变得十分高效。

2.在本地开发环境中反映 Pull Request 的内容

（1）在本示例中， Pull Request 接收方的用户名为 ituring，发送方的用户名为“PR 发送者”。
整体操作的框图如下：

（2）将接收方的本地仓库更新至最新状态
首先，将 Pull Request 接收方的仓库 clone 到本地开发环境中（图7.8 左侧）

（3）将 Pull Request 发送方的仓库设置为本地仓库的远程仓库
在本示例中，我们将图 7.8 右上的仓库设置为远程仓库，进行 fetch。
so，获取了 Pull Request 发送方仓库以及分支的数据（PR 发送者 /work）

（4）创建用于检查的分支：注意是检查用的，真正的操作在三、采纳 Pull Request的（2）中
我们需要创建一个分支，用来模拟采纳 Pull Request 后的状态。由于这是我们第一个 Pull Request，分支名就叫 pr1。
这一步相当于图 7.9 左侧箭头（checkout）代表的操作。
现在 gh-pages 与 pr1 分支的内容完全相同。

（5）将远程仓库的分支合并到本地的仓库的分支中
这样一来， pr1 分支中就加入了“PR 发送者 /work”分支的修改内容。

（6）删除pr1分支

三、采纳 Pull Request

（1）完成上述内容后，如果 Pull Request 的内容没有问题，大可打开浏览器找出相应的 Pull Request 页面，点击 Merge pull request 按钮，随后Pull Request 的内容会自动合并至仓库（图 7.10）

（2）不过，由于我们已经在本地构筑了相同的环境，只要通过 CLI 进行合并操作再 push 至 GitHub， Pull Request 中就会反映出 Pull Request 被采纳后的状态（图 7.11）。
这个状态对应到本示例中就是“PR 发送者 /work”分支合并到 gh-pages 分支。

具体操作如下：
（i）合并到主分支：将“PR 发送者 /work”分支就合并到了 gh-pages 分支中。

（ii）push 修改内容

结果：

四、小结

• 这种只有几行代码的 Pull Request，大可直接打开GitHub 网页点击合并
• 作为仓库的维护者要时刻记得，无法运行的代码绝不可以合入仓库，否则会失去团队对你的信任