接收到 Pull Request 后，会如图 7.1 中所示，在仓库的 Pull Request
标签页中显示别人发送过来的 Pull Request 的一览表。现在让我们点击
Pull Request 查看详细内容。
详细页面与我们发送 Pull Request 时的页面大致相同。点击 Merge
pull request 按钮（图 7.2），Pull Request 的内容便会自动合并至仓库。在
采纳之前，请尽量将接收到的 Pull Request 拿到本地开发环境中进行检
查，确认是否能够正常运行以及代码是否安全。或者用将要在第 8 章中
介绍的 Jenkins 等持续集成工具进行自动测试，保证新代码不破坏原有
功能之后，再合并进仓库。
采纳 Pull Request 前的准备
除确认 Pull Request 送来的代码是否运行正常外，各位还请在代码
审查上也多花些心思。GitHub 上可以快速高效地审查代码。下面我们就
来介绍这些功能。
学会使用各种各样的功能进行代码审查，要比以往使用工具的审查
轻松很多。如果团队中所有人都养成时常审查自己代码的习惯，其叠加
效果将不可估量。
● 代码审查
如图 7.3 所示，在 GitHub 上可以对 Pull Request 的具体的某行代码
进行评论。这让代码审查变得十分高效。
※ 每行前左侧的数字为该提交修改前的行号，右侧为修改后的行号。
发出评论之后相关人员会立刻接到 Notifications，无论是 Pull
Request 的发送方还是接收方，都能迅速反馈。由于 GitHub 的便捷性和
审查的简易性，让很多人离开 GitHub 之后在工作中倍感压力。
混迹于开源世界的程序员大多习惯使用 GitHub，所以如果能将
● 查看图片的差别
在 GitHub 上不但可以查看代码的差别，还有多种方法供用户查看
图片的差别。这些内容在官方博客
A
中有详细讲解，我们只在此挑出一
些介绍给各位。
官方博客已经介绍了用于演示的仓库
B ，所以各位实际操作一下该仓
库，就会发现这个功能有多么强大
C 。各位可以通过提交日志的 Image
View Mode Demo 来体验操作。
2 - up
2-up 可以同时显示一张旧图片和一张新图片，从而完成对比
（图 7.4）。
Swipe
Swipe 可以在分界线左右两侧分别显示旧图片和新图片（图 7.5）。鼠
标可以拖动分界线左右移动，帮助用户对比细节差异和细微的颜色差异
Onion Skin
Onion Skin 能够将新旧两张图片重叠放置，分阶段从旧图片慢慢过
渡至新图片，用户可以自由调节过渡比例（图 7.6）。通过这一功能，用
户能够一步步确认新图片相对于旧图片的变化。
Difference
Difference 功能让笔者都感到吃惊，它能够直接抽出两张图片不一
样的部分进行比较。如图 7.7 所示，Difference 抽出了单片眼镜这一差别
之处。
● 在本地开发环境中反映 Pull Request 的内容
下面我们来讲解收到 Pull Request 后在本地开发环境中进行实际检
查的流程。在本示例中，Pull Request 接收方的用户名为 ituring，发送方
的用户名为“PR 发送者”。
将接收方的本地仓库更新至最新状态
首先，将 Pull Request 接收方的仓库 clone 到本地开发环境中（图
7.8 左侧）。如果已经 clone 过，那么请进行 pull 等操作更新至最新状态。
获取发送方的远程仓库
将 Pull Request 发送方的仓库设置为本地仓库的远程仓库，获取发
送方仓库的数据。在本示例中，我们将图 7.8 右上的仓库设置为远程仓
库，进行 fetch。
$ git remote add PR发送者 [email protected]:PR发送者/first-pr.git
$ git fetch PR发送者
省略
From github.com:PR发送者/first-pr
* [new branch] gh-pages -> PR发送者/gh-pages
* [new branch] master -> PR发送者/master
* [new branch] work -> PR发送者/work
创建用于检查的分支
前面我们只获取了远程仓库的数据，这些数据尚未反映在任何一个
分支中。因此我们需要创建一个分支，用来模拟采纳 Pull Request 后的
状态。由于这是我们第一个 Pull Request，分支名就叫 pr1。这一步相当
于图 7.9 左侧箭头（checkout）代表的操作。现在 gh-pages 与 pr1 分支
的内容完全相同。
$ git checkout -b pr1
Switched to a new branch ‘pr1‘
合并
下面要将已经 fetch 完毕的“PR 发送者 /work”的修改内容与 pr1
分支进行合并。也就是图 7.9 下侧箭头（merge）代表的操作。
$ git merge PR发送者/work
Updating cc62779..243f28d
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
删除分支
检查结束后 pr1 分支就没用了，可以直接删除。我们切换至 pr1 之
外的分支，运行下面的代码。
$ git branch -D pr1
Deleted branch pr1 (was 243f28d).
采纳 Pull Request
完成上述内容后，如果 Pull Request 的内容没有问题，大可打开浏
览器找出相应的 Pull Request 页面，点击 Merge pull request 按钮，随后
Pull Request 的内容会自动合并至仓库（图 7.10）。
不过，由于我们已经在本地构筑了相同的环境，只要通过 CLI 进行
合并操作再 push 至 GitHub，Pull Request 中就会反映出 Pull Request 被
采纳后的状态（图 7.11）。这个状态对应到本示例中就是“PR 发送者 /
work”分支合并到 gh-pages 分支。
● 合并到主分支
首先，我们切换至 gh-pages 分支。
$ git checkout gh-pages
Switched to branch ‘gh-pages‘
然后合并“PR 发送者 /work”分支的内容。
$ git merge PR送信者/work
Updating cc62779..243f28d
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
● push 修改内容
现在只剩下 push 一步了，不过为保险起见，我们先查看本地与
GitHub 端仓库内代码的差别。
$ git diff origin/gh-pages
diff --git a/index.html b/index.html
index f2034b3..91b8ecb 100644
--- a/index.html
+++ b/index.html
@@ -39,6 +39,8 @@
<p>请写明这是对本书的实践或描述对本书的感想并发送Pull Request。</p>
+<p class="impression">这本书读着很有趣。（@HIROCASTER）</p>
+
省略
确认没有目的之外的差别后，进行 push。
原文地址：https://www.cnblogs.com/xyyhcn/p/11672533.html