接收Pull Request

采纳Pull Request前的准备

●代码审查

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

将接收方的本地仓库更新至最新状态首先，将Pull Request接收方的仓库clone到本地开发环境中。

将发送方的仓库fetch一份最新的到本地。

$ git remote add PR1 git@github.com:pr1/frist-pr.git
$ git fetch PR1

2. 获取发送方的远程仓库

将Pull Request发送方的仓库设置为本地仓库的远程仓库，获取发送方仓库的数据。

现在我们获取了Pull Request发送方仓库以及分支的数据

3.创建用于检查的分支

前面我们只获取了远程仓库的数据，这些数据尚未反映在任何一个分支中。因此我们需要创建一个分支，用来模拟采纳Pull Request后的状态。

$ git checkout -b pr1

4.合并

$ git merge PR1/work

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

5.删除分支

检查结束后pr1分支就没有用了，可以直接删掉。切换到其他分支后，执行如下命令：

$ git branch -D pr1

采纳Pull Request

●合并到主分支

//首先，我们切换至master分支。
$ git checkout master

//然后合并“PR发送者/work”
$ git merge PR1/work

这样“pr1发送者/work”分支就合并到master分支了。

●push修改内容

现在只剩下push一步了，不过为保险起见，我们先查看本地与GitHub端仓库内代码的差别。

$ git diff origin/master
$ git push

用这种方法处理后，仓库的Pull Request会自动从Open状态变为Close状态

以上便是安全接收Pull Request的流程。

Git这种分散型版本管理软件乍看上去非常复杂，但熟悉每一个操作后，运用起来还是很简单的。

不Fork仓库的方法

正常进行Pull Request的流程如下：

❶ 在GitHub上进行Fork


❷ 将❶的仓库clone至本地开发环境


❸ 在本地环境中创建特性分支


❹ 对特性分支进行代码修改并进行提交


❺ 将特性分支push到❶的仓库中


❻ 在GitHub上对Fork来源仓库发送Pull Request

然而在公司企业的开发中，开发者每天都要见面，要经常互相发送Pull Request，这种流程就显得有些繁琐了。

因此，下面我们要介绍一个不需要Fork仓库的工作流程。这种方法可以让每一名开发者都掌握着一个本地仓库和一个远程仓库，使整个开发流程变得简单。

GitHub Flow的流程

❶ 令master分支时常保持可以部署的状态
❷ 进行新的作业时要从master分支创建新分支，新分支名称要具有描述性
❸ 在❷新建的本地仓库分支中进行提交
❹ 在GitHub端仓库创建同名分支，定期push
❺ 需要帮助或反馈时创建Pull Request，以Pull Request进行交流
❻ 让其他开发者进行审查，确认作业完成后与master分支合并
❼ 与master分支合并后立刻部署

由于流程中基本只需为特定作业创建特定分支，从开始作业到进行部署之间的过程十分简单，可以降低开发者学习开发流程的成本。而且正由于其简单，所以大量开发者可以迅速将其利用到开发之中，并且可以借助它来灵活处理一些细微的代码变更。

下面我们按顺序一步步进行讲解。

1.随时部署，没有发布的概念

由于master分支时常保持着可以部署的状态，所以开发者可以随时创建新的分支。

要注意，没有进行过测试或者测试未通过的代码绝不可以合并到master分支。因此势必要用到持续集成等手段。

2.进行新的作业时要从master分支创建新分支

进行新的作业时要从master分支创建新分支，无论是添加新功能还是修复BUG都是如此。此外，新分支的名称要具有描述性。

例如如下命名方式：

●user-content-cache-key
●submodules-init-task
●redis2-transition

其他开发者可以通过这些名字清楚地了解到该分支正在进行什么工作。

采用这一方式，开发者在查看远程仓库的分支列表时，能够对当前团队正在实施的任务一目了然。

另外，由于分支名明确描述了工作内容，即便开发者需要先去做其他工作，回来时也能很快想起该分支的工作目标。

3.在新创建的分支中进行提交

在前面的步骤中，开发者为了进行新的更改而创建了新分支，并且明确了在这个分支中应该做哪些工作。接下来就可以在这个分支中修改代码，并进行提交了。修改代码时要注意，绝对不能进行与该分支工作内容无关的修改。

在这一阶段，开发者要在提交的粒度上多花心思。

有意识地减小提交的规模，一方面便于清楚地表达目的，另一方面有助于其他开发者对Pull Request进行审查。

4.定期push

在这一开发流程中，由于除了master分支之外都是作业中的分支，所以push作业分支时不需要有太多顾虑。

在开发过程中，建议开发者定期将本地仓库中创建的分支以同名形式push到GitHub端的远程仓库。这样一来不仅可以备份代码，还会定期给开发者团队创造交流的机会。其他开发者在做什么工作，是否需要帮助等，团队成员可以通过GitHub的分支列表页面一目了然。

5.使用Pull RequestPull Request

不一定非要在与master分支合并时才使用。既然是团队开发，完全可以尽早创建Pull Request让其他开发者进行审查，一边听取反馈一边编写代码，没必要等到与master分支合并时再进行。

6.务必让其他开发者进行审查

一个分支的作业结束后，需要注明作业已完成，让其他开发者进行审查。找其他开发者看一看自己编写的代码，可以有效防止想当然的错误或者低级失误。审查时要选择没有参与编写的人，被指出有问题时，要积极进行修改。当然，这一切的大前提是该部分代码已经通过所有自动测试。

7.合并后立刻部署

代码合并至master分支并且通过所有自动测试之后，需要立刻进行部署。在部署之后，需要确认刚刚合并的代码是否存在问题。