就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范
Vincent Driessen 同学为了解决这个问题提出了 A Successful Git Branching Model
下面是Git Flow的流程图，与SVN分支策略相比，Git分支流程复杂了很多，除了要维护两个长期的分支master和develop外，还有很多临时性分支如hotfix等，甚至有些用SVN分支思维的同学还有疑问，这种模式分支合并后岂不是增加了很多重复测试的工作量，因为理论上分支测试后，任何代码的改动合并到其它分支都是要重新回归测试才可以的。对此要用Git分支思维才能更好理解，Git用这样的分支策略就是为了应对实际中常出现的多人多版本并行开发的情况更方便有效率，如果实际开发过程中真像SVN开发分支线性向前迭代，则分支合并只是简单的移动分支指针并不用重新测试（因为它们是同一套代码）。
Git分支模型是考虑到基于版本分布，如果有些网站要“持续发布”，则没必要同时维护master和develop分支，为此GitHub和GitLab都做了对应的分支流程改进。
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 推荐的做法。
