介绍基于Git 两种协作开发模式
对于Github 一些好用的特殊操作技巧 ，可以见GitHub 特殊操作技巧 和Git的基本操作
GitHub FlowGitHub Flow —— 以部署为中心的开发模式,通过简单的功能和规则，持续且高速 安全地进行部署。在实际开发中往往一天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。
令master 分支时常保持可以部署的状态
进行新的作业时要从master 分支创建新的分支，新分支名称要具有描述性
在2新建的本地仓库分支中进行提交
在Github 端仓库创建同名分支，定期push
需要帮助、反馈，或者branch已经准备merging时，创建Pull Request，以Pull Request 进行交流
让其他开发者进行审查，确认作业完成后与master分支进行合并（合并的代码一定要测试
与master分支合并后，立刻部署
使用Github Flow 的前提条件
导入开发时注意事项：随着团队人数的增多及成熟度的提高，开发速度会越来越快。往往一个部署尚未完成，另一名开发者就已经处理完下一个pull request，开始实施下一个部署。在这种情况下，一旦正式环境出现问题，很难分辨哪个部署造成了影响。为了应对该情况，建议在部署实施过程中通过工具加锁。
Git Hook 自动部署
重视测试
让测试自动化
编写测试代码，通过全部测试
维护测试代码
荷兰程序员 Vincent Driessen 曾发表了一篇博客，让一个分支策略广为人知。具体流程见下图（引用该博客的一幅图片）
这一流程最大的亮点是考虑了紧急Bug的应对措施，整个流程显得过于复杂，所以在实施该方案前，需要对整个开发流程进行系统的学习。也需要借助Git flow 等工具的辅助。
GitHub 教程系列文章：
使用 GitHub / GitLab 的 Webhooks 进行网站自动化部署
下面根据上图，按块说明：
master 分支和 develop分支在Git Flow 中，这两个分支至关重要，它们会贯彻整个流程始终，绝对不会被删除。
master 分支
master 分支时常保持着软件可以正常运行的状态。由于要维护这一状态，所以不允许开发者直接对master 分支的代码进行修改和提交。
其他分支的开发工作进展到可以发布的程度后，将会与master分支进行合并，并且这一合并只在发布成品时进行。发布时将会附加版本编号的Git标签。
develop分支
develop分支是开发过程中代码中心分支。与master 分支一样，这个分支也不允许开发者直接进行修改和提交。
程序员要以develop分支为起点新建feature 分支，在feature 分支中进行新功能的开发或者代码的修正。也就是说develop分支维系着开发过程中的最新代码，以便程序员创建feature分支进行自己的工作。
在feature 中工作feature 分支以develop分支为起点，是开发者直接更改代码发送提交的分支。开发流程：
从develop分支创建feature分支
从feature分支中实现目标功能
通过Github 向develop发送pull request
接受其他开发者审核后，将Pull Request合并至develop分支
具体指令：
$ git checkout develop $ git pull $ git flow feature start add-user //add branch feature/add-user $ git branch // feature/add user start commit commit .... $ git push orgin feature/add-user //到github 上去代码审查，切到develop分支，进行pull request $ git checkout develop $ git pull // 当feature/add-user 合并到 develop后，本地develop 需要更新到最新状态