模拟体验GitHub Flow ¶

1. 创建新的分支 ¶

1.1 如果尚未clone仓库 ¶

首先需要Fork已经公开的仓库。如果尚未获取仓库，则需要使用下面的命令进行clone。各位请将仓库路径替换为自己的对应路径。

$ git clone git@github,com:ituring/fizzbuzz.git

在fizzbuzz目录下新建了一个仓库，这个仓库与远程仓库拥有相同状态。

1.2 如果之前clone过仓库 ¶

假设本地已经有之前clone来的仓库，现在正在开发途中并不需要重新clone，那么我们应该将master分支更新成远程仓库最新master分支的状态

$ git checkout master
$ git pull

通过以上操作，我们手头就有了最新状态的master分支。

2. 创建特性分支 ¶

现在我们已经完成了从master分支创建新分支的所有准备工作。我们将新分支的名字定为7-case-output-github。

//创建新分支，并切换到新分支。
$ git checkout -b 7-case-output-github

为方便团队其他人通过分支名称知道我们在做什么，我们在GitHub端的远程仓库中创建一个同名分支。

$ git push -u origin 7-case-output-github

创建分支大概就是这个步骤。今后我们可以每当工作告一段落时，定期将这个特性分支push到远程仓库。

3. 实现新功能 ¶

写代码…..

提交本次实现的新功能和需求

$ git commit -am "Add output GitHub"
//新功能已经顺利实现，现在将其push到远程仓库。
$ git push

GitHub端远程仓库中的分支应该已经被更新。

4. 创建Pull Request ¶

至此，我们已经顺利实现了新功能，接下来就是从7-case-output-github分支创建一个Pull Request发送给master分支，请求与master合并。

在Pull Request中写明希望得到审查。如果想让特定的人来进行审查，可以在评论中加入“@用户名”，这样该用户就会收到Notifications。

5. 接收反馈 ¶

至于测试代码，我们确实在添加新功能时没有添加相应的测试代码，对方指出的问题确实存在。

6. 修正被指出的问题 ¶

然后将修改提交至本地的7-case-output-github分支。

$ git commit -am "Fix index"
//该分支push到GitHub端的远程仓库，为远程仓库分支添加这项修改
$ git push

我们再打开GitHub查看Pull Request，会发现这个用于修正的提交已经添加至Pull Request

7. 添加测试 ¶

在GitHub Flow中，不可以将没有测试代码的成品代码加入master分支。因此我们被其他开发者指出没有编写测试代码了。

8. 培育Pull Request ¶

为了将我们编写的新功能合并到master分支中，要进行提交并push。

$ git commit -am "Fix output Github"
//该分支push到GitHub端的远程仓库，为远程仓库分支添加这项修改
$ git push

确认Pull Request没有问题之后，便可以通过评论请求与master合并了

9. Pull Request被合并 ¶

合并完成后，这个master分支将被立刻部署至正式环境。

习惯了在Pull Request上进行交流后，我们将能更精确地表达出代码的意图，审查的效率也会越来越快。熟练运用Pull Request是这一开发流程成功的关键。

团队实践GitHub Flow时的几点建议 ¶

●减小Pull Request的体积 ¶

开发时间越长或者代码量越大，代码审查时的成本就越高。过长的开发时间让审查者难以了解开发该功能时的背景，过大的代码量会让审查者难以阅读到代码的每个细节。这样一来BUG更容易出现，久而久之整个团队的代码审查都会漏洞频出。

●准备可供试运行的环境 ¶

我们不妨创建一个与正式环境高度相似的预演（Staging）环境，在这个预演环境中部署关键修改，借以确认代码的实际运行状况。当然，向预演环境的部署也需要实现自动化。

●不要让Pull Request中有太多反馈 ¶

一是交流不足。如果创建Pull Request的理由没有获得认同，那就不要通过PullRequest进行讨论，而是应该选择其他手段进行交流。最好的解决途径是直接面谈。

另一个原因是技术或能力不足。如果代码经常被指出问题，那么不是编程能力方面有问题，就是团队编写代码时没有一个明确的规则。为避免在无用的讨论上浪费时间，团队应该制定一个最低限度的编程规则，并且告知每一名团队成员。如果在开发过程中还需要其他规则，可以将这些规则整合到Wiki中，便于阅览及修改。

GitHub Flow是以部署为中心的开发流程，所以要求团队中每一名开发者都能编写出高品质的代码，以便顺利通过审查，迅速完成从合并到部署的过程。因此需要锻炼开发者，保证每一名团队成员都能达到这一水平。

●结对编程
●组织学习小组共享知识
●共享可供参考的资料

●不要积攒Pull Request ¶

建议团队制定一个新的规则：想创建Pull Request的人要先去对其他人的Pull Request进行审查及反馈，并在可以部署时及时部署。

这样一来，自己想创建Pull Request时必须先处理其他人的Pull Request，就可以有效避免Pull Request堆积的情况发生。

GitHub Flow的小结 ¶

●开发流程以部署为中心

●高速源于简单