This article briefly introduce Github Pull Request (hereinafter referred to as PR) to use:
- As a proponent of PR, PR on how to submit a warehouse, how to improve the PR warehouse management based on feedback submitted by the PR
- As a recipient of PR, PR how to test for author feedback and PR merge into the warehouse.
Here I use two GitHub account to be explained, PR recipient account is lml256, PR proponents account for the rikkaii. And to lml256 accounts learngit warehouse for testing.
How to Ask PR
If you are very interested in an open source project on Github, I want to contribute their efforts to add new features, or find some code bug, want their fix. So the open source warehouse to your warehouse Fork can list and modify it later, the original warehouse submit PR, request that the administrator of the repository into your code. Here we assume that the account is rikkaii, and to submit PR lml256 account in learngit project as an example, explain in detail the process:
Fork warehouse
Fork warehouse is very simple, you only need to tap the top right corner of the warehouse home Fork button, Github automatically creates a copy of the repository in your repository list.
As shown below, GitHub automatically creates a copy on your account, and indicates that the warehouse is a warehouse Fork come under the name of:
Adding new features
Now we add some new features to the warehouse:
The first clone to a local warehouse
$ git clone git@rikkaii:rikkaii/learngit.git
Cloning into 'learngit'...
remote: Enumerating objects: 65, done.
remote: Total 65 (delta 0), reused 0 (delta 0), pack-reused 65
Receiving objects: 100% (65/65), 5.44 KiB | 928.00 KiB/s, done.
Resolving deltas: 100% (17/17), done.We create a new branch from the master characteristic branch , and to achieve our new branch in the above characteristic features. Here is a brief description of what the feature branch: and will not be developed directly on the master git in the mainstream of development model, but rather in the development of a new branch of a function, called the topic branch on which to develop, until the development is completed after the test is completed and then merged into the master branch, and then delete the branch. And the name of the feature branch to be concise, easy to understand its role in others. Here we create a python-divbranch for the development of new features.
$ git checkout -b python-div
Switched to a new branch 'python-div'We create a directory in div.pythe file and write some code in it:
# div.py
# div.py
def div(a, b):
ans = a / b
return ans
Then submit, and pushed to GitHub:
$ git add div.py
$ git commit -m "add div.py"
[python-div 7aad1de] add div.py
1 file changed, 5 insertions(+)
create mode 100644 div.py
$ git push --set-upstream origin python-div
...
To rikkaii:rikkaii/learngit.git
* [new branch] python-div -> python-div
Branch 'python-div' set up to track remote branch 'python-div' from 'origin'.In the above command, since the python-div our local branch is new, and the remote repository GitHub no information of the branch, in order to push the modified branch on GitHub remote repository, when the push needed to add --set-upstreamparameters this will also create a python-div branch in the remote repository and push up the modification of the branch.
We can see that our warehouse has been python-div branch and commit this file div.py added.
PR launched
Next, you can click on the image above branch next to the name of the New pull Request button to initiate a PR. This will automatically jump to the original warehouse below, and select python-div as a branch to be pushed, as follows:
As you want to modify the python-div branch pushed to what branch of the original warehouse, Github here automatically selects the master branch for us to note here is the choice of branch development model and what about the original warehouse, general formal open source warehouse will explain PR submission rules, including submitting to what branch and how to describe commit, etc., which we need to carefully read and follow the relevant requirements. For convenience herein demonstrate, the python-div branch modification request is pushed onto the original master repository, and only use the default GitHub explained in the following description column of FIG.
Then you can click on the Create pull request button on the chart below to create a branch of.
When the map appears on the way, we created a PR success. We just need to quietly wait for the warehouse manager of the audit on the line.
Correction PR
However, some things always backfire, sometimes we think that our code is not the problem, but was the warehouse manager feedback (or by other developers point out) our code in question, we need to fix. Administrator after our code of conduct audit pointed out our mistakes, Github will also administrator between us and other developers and (here and no other developer) to discuss the times reflected in the PR on the timeline, and we will inform our mail in the form of:
Next, we follow the requirements of the warehouse manager, to improve the code, the code is modified as follows:
# div.py
def div(a, b):
try:
ans = a / b
except ZeroDivisionError as e:
print('error:', e)
return None
return ans
After editing, the code submitted and pushed to GitHub:
$ git add div.py
$ git commit -m "fix zero division error"
[python-div c3b73e7] fix zero division error
1 file changed, 5 insertions(+), 1 deletion(-)
$ git push
...
To rikkaii:rikkaii/learngit.git
7aad1de..c3b73e7 python-div -> python-div当我们推送完后，无需再次发起PR，Github会自动的将该次的提交反映到原来PR时间轴上，如下图，并且Github还会向管理员发送邮件通知本次修改：
当仓库管理者通过了本次代码，将我们的代码合并到了master分支中后，我们也会收到Github发来的关于Merge本次PR的邮件通知。
接收PR
说完了如何提交PR，我们再说一说如何接收PR。作为一个开源项目的管理者，学会如何测试别人提出的PR并进行反馈或者合并是很必要的。这里假设我们的账号为lml256，以接收rikkaii账号向lml256账号中的learngit仓库提交的PR为例，详细的说明一下作为仓库的管理者，如何测试和合并PR。
审计PR
打开我们的仓库，在Pull Requests列表中可以看到rikkaii向我们的仓库提交了一个PR
点进去可以看到详细的信息：
我们可以在Files changed栏里对代码进行审计，如果代码有问题的话，可以对每行代码添加批注，以帮助PR提交者进行完善，写完批注后，点击start a review便可发起一个code review。如下：
当代码全部都审计完后，点击下图中的submit review便可以提交本次的审计结果。
提交后，我们对代码的审计结果便会反映在该PR的时间轴上，并且GitHub会向PR发起者发送回复通知邮件。
对PR进行本地测试
只在Github上凭借眼睛看并不能发现所有的问题，在对PR正式合并前，我们还需要对PR进行本地测试，如何使用git进行操作如下图：
首先我们需要将我们仓库的代码clone到本地（也可能不需要clone，如果本地已经有该仓库的话），然后拉取PR发起者仓库的相关信息，这需要我们先将PR发起者Fork的仓库添加到本地仓库的远程仓库：
$ git remote add PR_Sponsor git@rikkaii:rikkaii/learngit.git
$ git fetch PR_Sponsor # 获取PR发起者仓库的相关信息
...
From rikkaii:rikkaii/learngit
* [new branch] dev -> PR_Sponsor/dev
* [new branch] master -> PR_Sponsor/master
* [new branch] python-div -> PR_Sponsor/python-div可以看到，我们从PR发起者仓库中获取到三个分支，其中包括为我们提交PR的python-div分支。
在进行测试之前，我们还需要创建一个特性分支用于测试PR，并将python-div分支的修改merge到特性分支上进行测试：
$ git checkout -b test_pr
Switched to a new branch 'test_pr'
$ git merge PR_Sponsor/python-div
Updating 9053d5b..c3b73e7
Fast-forward
div.py | 9 +++++++++
1 file changed, 9 insertions(+)
create mode 100644 div.pyMerge代码
经过一番测试后，我们确信该PR的代码没有问题，可以合并代码到PR发起者要求合并到的分支上（这里是master）。这里有两种方法来处理这个问题，一是直接使用GitHub提供的Merge按钮，这种方法比较直观方便，但是不够灵活，无法处理合并冲突；二是在本地将测试后的特性分支合并到要合并的分支上，然后手动提交。尽管第二种方式处理起来比较复杂，但是却比较灵活，可以处理Github不能胜任的地方。这里我们选择第二种：
$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$ git merge test_pr
Updating 9053d5b..c3b73e7
Fast-forward
div.py | 9 +++++++++
1 file changed, 9 insertions(+)
create mode 100644 div.py
$ git branch -d test_pr # 这里我们的特性分支已没作用，可以删除
Deleted branch test_pr (was c3b73e7).
$ git push
...
To lml256:lml256/learngit.git
9053d5b..c3b73e7 master -> master这里，我们已经处理完了该PR，同时，GitHub也会检测到我们合并了该PR，也将其反映到该PR的时间轴上，并将该PR的状态设置为Merged状态，关闭该次PR：
完
版权所有，未经允许不得转载