最近我们团队对日常开发规范和版本控制等工作进行了调整，为此对GitFlow工作流以及它的各类变种也进行了学习，在此记录一下。
只有一个Master分支带来的问题
首先我们回顾一下我们在日常与团队的合作开发一个项目中会遇到与版本控制相关的场景。
一般我们在创建一个Git仓库的时候会有一个默认的主分支 master分支，默认情况下我们所有的开发工作（提交、合并。。）都在这个主分支上，也确实存在许多的团队就在一个master分支上进行所有的开发活动。
那么如果只有一个master分支会有哪些问题？
（1）场景一：当我们正在开发新的功能的时候，经理要求紧急上线一个版本
（2）场景二：已经上线的版本存在Bug,需要紧急修复，但是目前正在进行新功能开发。
显然如果我们只有一个master分支，所有的版本发布、Bug修复、新功能开发都在一个分支上开发，我们将会遇到许多问题，master分支上将同时存在正在开发中的代码、已经开发完但未经测试的代码、存在Bug的Tag版本等等一个比较混乱的情况。
如果此时想要发布一个版本，我们必须从众多的的提交记录中找到一个最近但经过测试的TAG去发布，但是我们修复Bug的提交可能不在这个TAG之前。。。。。
GitFlow解决问题的方式
GitFlow工作流如何通过多个分支解决 随时发版、线上Bug解决、新功能同步开发等我们工作中经常遇到的问题？
一个典型的GitFlow工作流会包括 master、develop、release、以及feature分支
master分支是一个受到严格控制的主分支，所有的代码在提交到master直接必须受到检查，确保master上的代码是功能完整、经过测试并随时可以进行版本发布的。
develop分支develop是开发分支，是所有分支中代码最完整、最新的分支，确保所有的提交都会在develop分支中存在，在开发新功能时我们从develop分支上创建一个feature分支专门进行某一个功能的开发，当该功能完成后合并到develop分支此feature分支也会被删除。
release分支是版本发布分支，会存在 V1.0.1-release,V1.0.2-release。。。等众多release分支，每个release分支都是从master分支上创建而来。
bugfix可以用来针对release分支进行Bug修复，属于临时分支，当修复了某个发布版本的Bug后，需要同时将代码合并到master和develop分支上。
。。。待续图表整理
