一、工作流程存在的意义
- Git 作为一个源码管理系统，不可避免涉及到多人协作。
- 协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
二、共同点
- 本文的三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD，维基百科）。
- 它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
三、工作流介绍
Git 工作流程(阮一峰完整总结版本，各流程变化，且有独到见解)
Git flow工作流评价：
- Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将
master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。 - 更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，
master分支和develop分支的差别不大，没必要维护两个长期分支。
GitHub flow工作流评价：
- Github flow 的最大优点就是简单，对于"持续发布"的产品，可以说是最合适的流程。
- 问题在于它的假设：
master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。 - 可是，有些时候并非如此，代码合并进入
master分支，并不代表它就能立刻发布。比如，苹果商店的APP提交审核以后，等一段时间才能上架。这时，如果还有新的代码提交，master分支就会与刚发布的版本不一致。另一个例子是，有些公司有发布窗口，只有指定时间才能发布，这也会导致线上版本落后于master分支。 - 上面这种情况，只有
master一个主分支就不够用了。通常，你不得不在master分支以外，另外新建一个production分支跟踪线上版本。
Gitlab flow工作流：
- Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
其他请参考Git 工作流程(阮一峰完整总结版本，各流程变化，且有独到见解)