承接上文，人傻就要多学习系列，在记录完git的常用方法后，又学习了github的灵魂功能pull request，是团队开发和开源必不可少的工具。
同样，本文没有任何截图，都是文字阐述，更像是我的个人笔记。对纯小白不是很友好，若不喜欢这类形式可以选择性关闭。
Pull Request
Pull Request(以下简称pr)是自己修改源代码后，请求对方仓库采纳该修改方式时的一种行为，能更好的实现多人开发。
如发现了一个软件的BUG并修改后，在github上发送了pr，接收方的仓库会创建一个附带源代码的issue，在这个issue里详细记录内容。发送过去的pr是否被采纳，要由接收方的管理者进行判断。如果被接收，pr的发起者就会变成这个项目的contributor，也就变成了开源软件的贡献者。
发送pr
发送前的准备
fork:在对方的仓库中点击fork按钮，然后会发现自己的仓库中也有了对应的仓库。(当然也可以不用进行fork，假设团队的成员对仓库都有编辑的权限时，可以免去fork这一步骤)clone:复制自己fork仓库的URL，建议以SSH协议将仓库克隆到本地仓库中。此时修改仓库内容并push，只会修改自己的仓库，不会修改他人的仓库，这也是github的一大优势。branch:创建特性分支然后在分支中修改代码，这是个好习惯。因为在给对方仓库pr时都是发送特性分支，这样对方仓库就能根据分支来更好的理解代码的意图。如修改错别字分支，那么就git branch typo。git branch -a查看分支，开头带有remotes/origin/的是github端仓库的分支。- 在修改完代码后，提交修改。
git add filename还有git commit -m "comment"。 - 要从
github发送pr，github仓库端必须有一个包含了修改代码后的分支，所以就创建本地typo分支的远程分支，git push origin typo即可。
发送期间
登录github并切换到typo分支，确认发送的内容准确无误后，点击create pull request，然后在表单中填写本次pr的理由和改进即可。
再次确认无误后，点击send pull request，这样，pr的目标仓库就会新建pr和issue，至于对方仓库接收与否，还得看仓库原作者的想法了。
注意事项
在程序的开发过程中，pr是对软件实现和功能探讨的好方法。当然更建议的是不要写完代码在pr，而是可以尽早的pr获得反馈，统一大家的开发思路，提高代码质量。否则一声不吭的写完并pr后，会导致一个功能开发完毕后才能得到修正，甚至要大幅度改变代码，很浪费经历。
所以，只想要发起讨论的时候pr即可，不必等代码有所实现。即使对某个正在开发的功能提供简短的伪代码让大家有个印象，也能获得不少反馈。如被他人指正自己没注意到的小错误，或功能的修改意见，或已经有他人实现的代码等，能让自己避免浪费不必要的精力。这种边审查边开发的过程，比开发完在审查高效的多。
但需要注意的是，在发送的一个pr或者issue中，不要讨论无关的东西，当需要讨论另外的内容时，重新开一个pr即可。
仓库的维护
当然在fork和clone后想修改代码，但因某些不可避免的原因搁置了。而远程仓库一直在开发，则此时本地的仓库和远程的最新仓库难免有很多不同之处，所以要让本地的仓库保持最新的状态:
- 首先给目标仓库设置一个名称，这里叫上游
upstream，git remote add upstream git://github.com/user/repo.git作为远程仓库。 - 然后
git fetch upstream就能从远程仓库获取最新的代码，将upstream/master分支与当前分支合并，以此来获取远程仓库的最新状态。
接收pr
接收到他人发送的pr后，点击即可查看详细内容，在检测完他人发送pr的代码准确无误后，点击merge pull request按钮就会将内容自动合并到仓库的主分支。
接收前的准备
- 审查代码，对代码作出必要的注释和评论，点击代码左侧的
+号即可。 - 将
pr接收方的仓库clone到本地(不要操作原有的仓库)，如果已经克隆，可以git pull获取最新状态。 - 然后获取
pr发送方的仓库，设置为本地仓库的远程仓库:git remote add pr-sender git@github.com:pr-sender/repo.git，并git fetch合并。 - 创建用于检测的分支
test，将fetch完的分支和test分支合并，这样test分支就捕获了他人发送pr的分支。 - 检查代码无误后
git branch -D test删除此分支即可。 - 确认无误后，进入浏览器，点击
merge pull request即可，自动合并仓库，仓库的pr会自动从open变为close。
注意事项
- 无法运行的代码不要合并到仓库;
- 不要发布错误的不能运行的代码;
