《GitHub入门与实战》第七章

第七章　接收Pull Request

7.1　采纳 Pull Request 的方法

  接收到 Pull Request 后，在仓库的 Pull Request 标签页中显示别人发送过来的 Pull Request 的一览表。点击 Pull Request 查看详细内容。
  详细页面与发送 Pull Request 时的页面大致相同。点击 Merge pull request 按钮，Pull Request 的内容便会自动合并至仓库。在采纳之前，请尽量将接收到的 Pull Request 拿到本地开发环境中进行检查，确认是否能够正常运行以及代码是否安全。或者用 Jenkins 等持续集成工具进行自动测试，保证新代码不破坏原有功能之后，再合并进仓库。

7.2　采纳 Pull Request 前的准备

  除确认 Pull Request 送来的代码是否运行正常外，还请在代码审查上也多花些心思。GitHub 上可以快速高效地审查代码。
  学会使用各种各样的功能进行代码审查，要比以往使用工具的审查轻松很多。如果团队中所有人都养成时常审查自己代码的习惯，其叠加效果将不可估量。

代码审查

  在 GitHub 上可以对 Pull Request 的具体的某行代码进行评论。这让代码审查变得十分高效。

  • 每行前左侧的数字为该提交修改前的行号，右侧为修改后的行号。

  发出评论之后相关人员会立刻接到 Notifications，无论是 Pull Request 的发送方还是接收方，都能迅速反馈。
  混迹于开源世界的程序员大多习惯使用 GitHub，所以如果能将 GitHub 应用到工作中，就可以免去适应公司独有开发环境带来的压力。这也是公司导入 GitHub 的优势所在。

查看图片的差别

  在 GitHub 上不但可以查看代码的差别，还有多种方法供用户查看图片的差别。这些内容在官方博客https://github.com/blog/817-behold-image-view-modes中有详细讲解。

  官方博客已经介绍了用于演示的仓库 https://github.com/cameronmcefee/Image-Diff-View-Modes，所以实际操作一下该仓库，就会发现这个功能有多么强大。各位可以通过提交日志的 Image View Mode Demo 来体验操作。

2-up

  2-up 可以同时显示一张旧图片和一张新图片，从而完成对比。

Swipe

  Swipe 可以在分界线左右两侧分别显示旧图片和新图片。鼠标可以拖动分界线左右移动，帮助用户对比细节差异和细微的颜色差异。

Onion Skin

  Onion Skin 能够将新旧两张图片重叠放置，分阶段从旧图片慢慢过渡至新图片，用户可以自由调节过渡比例。通过这一功能，用户能够一步步确认新图片相对于旧图片的变化。

  像这样，使用 GitHub 不但可以比较代码，还能够高效地对比图片。各位不妨让负责美工的同事也来试试。

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

  收到 Pull Request 后在本地开发环境中进行实际检查的流程。在本示例中，Pull Request 接收方的用户名为 ituring，发送方的用户名为“PR 发送者”。

将接收方的本地仓库更新至最新状态

  首先，将 Pull Request 接收方的仓库 clone 到本地开发环境中。如果已经 clone 过，那么请进行 pull 等操作更新至最新状态。

$ git clone git@github.com:ituring/first-pr.git
Cloning into 'first-pr'...
remote: Counting objects: 34, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 34 (delta 10), reused 15 (delta 4)
Receiving objects: 100% (34/34), 89.48 KiB | 112 KiB/s, done.
Resolving deltas: 100% (10/10), done.
$ cd first-pr

获取发送方的远程仓库

  将 Pull Request 发送方的仓库设置为本地仓库的远程仓库，获取发送方仓库的数据。在本示例中，将仓库设置为远程仓库，进行 fetch。

$ git remote add PR发送者 git@github.com: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 发送方仓库以及分支的数据（PR 发送者 /work）。

创建用于检查的分支

  前面我们只获取了远程仓库的数据，这些数据尚未反映在任何一个分支中。因此我们需要创建一个分支，用来模拟采纳 Pull Request 后的状态。由于这是我们第一个 Pull Request，分支名就叫 pr1。现在 gh-pages 与 pr1 分支的内容完全相同。

$ git checkout -b pr1
Switched to a new branch 'pr1'

合并

  将已经 fetch 完毕的“PR 发送者 /work”的修改内容与 pr1 分支进行合并。

$ git merge PR发送者/work
Updating cc62779..243f28d
Fast-forward
 index.html |    2 ++
 1 file changed, 2 insertions(+)

  这样一来，pr1 分支中就加入了“PR 发送者 /work”分支的修改内容。本示例中我们只修改了 index.html 文件，所以检查一下 index.html 有没有显示错误即可。在实际开发中，各位需要通过自动测试等手段检查软件是否能正常运行。

删除分支

检查结束后 pr1 分支就没用了，可以直接删除。我们切换至 pr1 之外的分支。

$ git branch -D pr1
Deleted branch pr1 (was 243f28d).
  • 提升代码管理技术

  如果能灵活运用分支的创建及合并，便可以在确保安全性的前提下并行开发多个功能。这一技术在软件开发现场非常有用，而且团队规模越大效果越好。
  想学会安全又专业的源代码管理，不妨先多多尝试 Git 与 GitHub。

7.3　采纳 Pull Request

  如果 Pull Request 的内容没有问题，大可打开浏览器找出相应的 Pull Request 页面，点击 Merge pull request 按钮，随后 Pull Request 的内容会自动合并至仓库。
  由于已经在本地构筑了相同的环境，只要通过 CLI 进行合并操作再 push 至 GitHub，Pull Request 中就会反映出 Pull Request 被采纳后的状态。这个状态对应到本示例中就是“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(+)

  这样一来“PR 发送者 /work”分支就合并到了 gh-pages 分支中。

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。

$ git push
......
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:ituring/first-pr.git
   cc62779..243f28d local_gh-pages -> gh-pages

  用这种方法处理后，仓库的 Pull Request 会自动从 Open 状态变为 Close 状态。现在我们可以去查看网页，已采纳的源代码应该已经反映出来了。
  Git 这种分散型版本管理软件乍看上去非常复杂，但熟悉每一个操作后，运用起来还是很简单的。

7.4　小结

  本文中我们讲解了如何安全地接收 Pull Request。
  本次示例中这种只有几行代码的 Pull Request，大可直接打开 GitHub 网页点击合并，但在实际的开发现场中，接收到的 Pull Request 往往会更加复杂，有时甚至与多个文件挂钩。
  作为仓库的维护者要时刻记得，无法运行的代码绝不可以合入仓库，否则会失去团队对你的信任。另外还要注意，不要发布那些无法运行的、没有通过测试的、有语法错误的源代码。

©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容