GitHub Flow工作流

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反复反馈、交流，需提高编码能力和编码规范等，一些措施：结对编程、共享知识、共享资料