GitHub Flow 开发流程：以部署为中心
0. 始终保持master主干分支为可发布、部署的状态(这样可以时刻被创建特性分支或者可以被部署)
1. 新特性、作业或者修改BUG，从主干分支创建新的本地分支(该分支应具有描述性的名称)，若该分支已存在，应先git pull更新为远程仓库master主干分支的最新状态
2. 确认在本地环境中通过所有测试，此后便可修改新建的本地分支下内容(一般只修改一定小粒度的内容)并在该分支中进行提交(修改内容前一般需要先编写测试代码)
3. 在gihub端的仓库中创建同名的分支，并push操作(即在该分支下创建远程分支)
4. 此外可通过Pull Request反馈、交流(整个过程可能多次被请求审查、重新修改等直到完成作业)
5. 让其他开发者进行审查，待确认后再与master主干分支进行合并(事实上应现在本地测试通过)
6. 与master主干分支合并后即刻部署，而在部署到正式环境之前需要先通过测试(包括测试代码编写、自动化测试、持续集成等工具
(部分部署工具: Capistrano、Mina、Fabric、Cinnamon、Webistrano、Strano等，持续集成IC: Jenkins、Travish CI等))
GitHub Flow流程的过程中的一些建议：
0. 每次的Pull Request应该尽可能细分到足够小，分成多个小的Pull Request，以减少审查的成本开销
1. 可实验、运行的测试环境，在该环境中测试某个小的修改或是增加的功能
2. 避免过多的Pull Request反复反馈、交流，需提高编码能力和编码规范等，一些措施：结对编程、共享知识、共享资料
