6.1 Pull Request 的概要
-
什么是 Pull Request
Pull Request 是自己修改源代 码后，请求对方仓库采纳该修改时采取的一种行为。
-
Pull Request 的流程
假设我们在使用 GitHub 上的一款开源软件。 在使用这款软件的过程中，我们偶然间发现了BUG。为了继续使用软件，我们手动修复了这个BUG。如果我们修改的这段代码能被该软件的开发仓库采纳，今后与我们同样使用这款软件的人就不会再遇到 这个 BUG。
为此，我们要第一时间发送 Pull Request。 在 GitHub 上发送 Pull Request后，接收方的仓库会创建一个附带源代码的 Issue，我们在这个 Issue 中记录详细内容。这就是 Pull Request。
6.2 发送 Pull Request 前的准备
整体概念如下：
-
查看要修正的代码
登录 https://ituring.github.io/first-pr，该网站的源代码已经在 GitHub 上公开（https://github.com/ituring/first-pr）。各位请将自己的感想写入源代码，然后发送 Pull Request。
-
Fork
访问 https://github.com/ituring/first-pr，点击 Fork 按钮创建名为“自己的账户名/first-pr”的仓库。
-
clone
clone 仓库所需的访问信息显示在右侧的中央部分，让我们将它复制下来(SSH)，把这个仓库 clone 到当前的开发环境中
$ git clone git@github.com:Jun-Dong/first-pr.git Cloning into 'first-pr'... remote: Counting objects: 5971, done. remote: Compressing objects: 100% (10/10), done. remote: Total 5971 (delta 6), reused 14 (delta 6), pack-reused 5955 Receiving objects: 100% (5971/5971), 1.40 MiB | 333.00 KiB/s, done. Resolving deltas: 100% (3716/3716), done. $ cd first-prfirst-pr 目录下会生成Git仓库。这个仓库与我们 GitHub 账户下的 first-pr 仓库状态相同。现在只要在这个仓库中修改源代码进行push， GitHub 账户中的仓库就会被修改。
-
branch
1. 为何要在特性分支中进行作业
当前Git的主流开发模式都会使用特性分支；
在 GitHub上发 送 Pull Request 时，一般都是发送特性分支。这样一来，Pull Request就 拥有了更明确的特性（主题）。让对方了解自己修改代码的意图，有助于提高代码审查的效率。
2. 确认分支
$ git branch -a * gh-pages remotes/origin/HEAD -> origin/gh-pages remotes/origin/feature/move-jquery-from-cdn-to-local remotes/origin/gh-pages开头加了“remotes/origin/”的是 GitHub 端仓库的分支。
我们手头的开发环境中只有 gh-pages 分支。 网站中显示的HTML位于/origin/gh-pages分支。虽然通常情况下最新版代码都位于 master分支，但由于本次我们使用了 GitHub Pages， 所以最新代码位于 gh-pages 分支。
3. 创建特性分支
现在创建名为 work 的特性分支并自动切换，其用于发送 Pull Request。
$ git checkout -b work gh-pages Switched to a new branch 'work'确认是否切换到 work 分支下
$ git branch -a gh-pages * work remotes/origin/HEAD -> origin/gh-pages remotes/origin/feature/move-jquery-from-cdn-to-local remotes/origin/gh-pages查看文件列表
$ dir images index.html javascripts params.json README.md stylesheets
-
添加代码
用编辑器打开 index.html文件，以 HTML 形式添加感想。
省略 <p>请写明这是对本书内容的实践或描述对本书的感想并发送Pull Request。</p> ↓追加的行 <p class="impression"> 这本书读着很有趣。（@HIROCASTER）</p> 省略 -
提交修改
用 git diff 命令查看修改是否已经正确进行。
$ git diff diff --git a/index.html b/index.html index f684b22..061b6d7 100755 --- a/index.html +++ b/index.html @@ -74,6 +74,8 @@ <select class="select"></select> <section class="wrap"> +<p>这是对本书的感想并发送Pull Request。</p> +<p class="impression">2018/04/20 Hello GitHub</p>确认浏览器显示是否正确，并提交至本地仓库。
$ git add index.html Jadon@LAPTOP-QTBB80RR MINGW64 ~/Desktop/PyProjects/GitHub/first-pr (work) $ git commit -m "Add my impression" [work f66a624] Add my impression 1 file changed, 2 insertions(+) -
创建远程分支
要从 GitHub 发送 Pull Request，GitHub 端的仓库中必须有一个包含了修改后代码的分支。
我们现在就来创建本地 work 分支的相应远程分支。
$ git push origin work Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 355 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 2 local objects. To github.com:Jun-Dong/first-pr.git * [new branch] work -> work查看分支，/origin/work 已被建立。
$ git branch -a gh-pages * work remotes/origin/HEAD -> origin/gh-pages remotes/origin/feature/move-jquery-from-cdn-to-local remotes/origin/gh-pages remotes/origin/work
打开https://github.com/用户名/first-pr，确认 work 分支是否被创 建，以及是否已包含我们添加的代码。
6.3 发送 Pull Request
点击如下按钮，比较分支之间的差异。
确认无误后，简要的描述进行 Pull Request 的理由并发送。这样一来，Pull Request 的目标仓库中就会新建 Pull Request 和 Issue，同时该仓库的管理者会接到通知。
至此，我已经发送了第一次的 Pull Request。现但是发送的源代码还没有被采纳，对方仓库不会有任何变化，所以网页也仍然是原样。
-
如何查看已发送 Pull Request的状态
如果想查看已发送 Pull Request的状态，可以登录 GitHub，打开自己的控制面板查看 Pull Request 标签页。点击自己发送的 Pull Request 后会进入如下图的页面，管理者对 Pull Request 的评论会发到这里。这些在 Conversation 标签页中会按照时间顺序排列显示。
6.4 让 Pull Request 更加有效的方法
-
在开发过程中发送 Pull Request 进行讨论
- 在实际开发过程中，等代码完成后在发送 Pull Request，这样做很可能导致一个功能在完成后才收到设计或实现方面的指正，从而使代码需要大幅更改或重新实现。
- 所以尽早发送 Pull Request（写个伪代码），想讨论时就发送 Pull Request，不必等代码最终完成。
- 从审查中获得反馈， 让大家在设计与实现方面思路一致，借此逐渐提高代码质量。
- 不要在 Pull Request中添加无关的修改。若要处理与主题无关的作业请另外创建分支，不然会让原本清晰的讨论变得一团糟。
-
明确标出“正在开发过程中”
为防止开发到一半的 Pull Request 被误合并，一般都会像图中所示的那样在标题前加上“[WIP]”字样。
WIP 是 Work In Progress 的简写，表示仍在开发过程中。等所有功能都实现之后，再消去这个前缀。
-
不进行 Fork 直接从分支发送 Pull Request
一般说来，在 GitHub 上修改对方的代码时，需要先将仓库 Fork 到 本地，然后再修改代码，发送 Pull Request。
但是，如果用户对该仓库有编辑权限，则可以直接创建分支，从分支发送 Pull Request。利用这一设 计，团队开发时不妨为每一名成员赋予编辑权限，免去Fork仓库的麻烦。这样，成员在有需要时就可以创建自己的分支，然后直接向 master 分支等发送 Pull Request。
6.5 仓库的维护
下面就让我们学习如何让仓库保持最新状态。
通常来说 clone 来的仓库实际上与原仓库并没有任何关系。所以我们需要将原仓库设置为远程仓库，从该仓库获取（fetch）数据与本地仓 库进行合并（merge），让本地仓库的源代码保持最新状态。
-
仓库的 Fork 与 clone
地址：https://github.com/octocat/Spoon-Knife，将 octocat/Spoon-Knife作为原仓库，在 GitHub上进行 Fork，然后 clone。
$ git clone git@github.com:Jun-Dong/Spoon-Knife.git Cloning into 'Spoon-Knife'... remote: Counting objects: 16, done. remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16 Receiving objects: 100% (16/16), done. Resolving deltas: 100% (3/3), done. -
给原仓库设置名称
我们给原仓库设置 upstream 的名称，将其作为远程仓库。
$ cd Spoon-Knife Jadon@LAPTOP-QTBB80RR MINGW64 ~/Desktop/PyProjects/GitHub/Spoon-Knife (master) $ git remote add upsteam git://github.com/octocat/Spoon-Knife.git今后，我们的这个仓库将以 upstream作为原仓库的标识符。这个环 境下只需要设定一次。
-
获取最新数据
下面我们从远程仓库实际获取（fetch）最新源代码，与自己仓库的分支进行合并。要让仓库维持最新状态，只需要重复这一工作即可。
$ git fetch upsteam From git://github.com/octocat/Spoon-Knife * [new branch] change-the-title -> upsteam/change-the-title * [new branch] master -> upsteam/master * [new branch] test-branch -> upsteam/test-branch通过 git fetch 命令获取最新的数据，将 upsteam/master 分支与当前（master）分支合并。这一操作确实可以将最新的源代码合并至当前分支。
这样一来，当前分支（master）就获得了最新的源代码。在创建特性分支，编辑源代码之前，建议先将仓库更新到这一状态。一般情况下，master 分支都会获取最新代码，很少需要 Fork 的开发者亲自进行 修正。
网友评论