首先，介绍一下gitflow，它是最早诞生、并得到广泛采用的一种工作流程。如果采用git flow开发流程，那么项目存在两个常设分支，一个叫主分支master，另一个叫开发分支develop。master分支中存放的是用于发布的版本，而develop存放的是用与日常开发的版本。此外，项目可能还会存在一些临时性分支包括：功能分支，补丁分支，预发分支。常用到的命令有：
Git创建Develop分支的命令：
git checkout -b develop master
将Develop分支发布到Master分支的命令：
# 切换到Master分支 git checkout master
# 对Develop分支进行合并 git merge --no-ff develop
gitflow的优缺点：
Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。
更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。
下面我们介绍一下github flow
github flow是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程。
它的流程如下：
第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
github flow的优缺点:
github flow流程很简单，特别适合持续发布的产品，部署完全自动化。团队最好控制在15-20人，随着团队人数的增多及成熟度的提高，开发速度会越来越快。往往一个部署尚未完成，另一名开发者就已经处理完下一个pull request，开始实施下一个部署。在这种情况下，一旦正式环境出现问题，很难分辨哪个部署造成了影响。为了应对该情况，建议在部署实施过程中通过工具加锁。
根据以上衡量，我们团队只有4人，而且不需要做到连续化发布，做的四则运算功能其实很简单，要用到的develop分支节点较少，所以我们组决定采用git flow流程进行java web开发。
ps:由于电脑出现了一点问题，所以没能插入图片
答题者：徐潇瑞