Git Flow工作流规范的使用
前言
通常在我们的项目开发过程中，在版本控制流程里没有一个规范去约束，往往会导致git的分支混乱，以及难以管理的问题发生，因此为了规避这些问题的产生，我们也会去定义一系列的git规范。在网上现在比较流行的则是Git Flow工作流。
注意事项
博主在使用 Git Flow 的过程中发现，不是所有的团队都适用于 Git Flow 这个规范。
比如你的项目组成员在10人以下，这个时候因为项目组规模较小，使用 Git Flow 工作流往往会增加不必要的操作，从而导致时间成本的增加。
例如博主本人所管理的项目组是根据 Git Flow 做了一些删减，保留必要的发布流程以外，针对功能的开发并没有使用更多的分支去规范化的管理。而且在这个删减的规范中，还能使用 rebase 去美化我们的分支。
但如果您所管理的团队人数较多，那您一定要试试 Git FLow 工作流的规范了。
工作流模型介绍
上图是工作流模型的图片，那么下面博主大致介绍下每个分支的介绍
分支介绍
Master分支: 每个项目有且仅有一个
master分支，作为主分支。主要用来存储正式发布的产品，该分支上的代码要随时处于可部署的状态。master分支只能通过合并其他分支来更新内容，禁止直接在master分支上进行修改.Develop分支: 该分支是开发分支，允许确实功能模块，但已有的功能模块一定是开发完成的。该分支同样也是只能通过合并其他分支进行内容的更新。
Feature分支: 该分支是功能分支，当要开发新功能或者试验新功能时，从
develop分支创建一个新的feature分支，并在feature分支上进行开发。开发完成后，需要将该分支合并到develop分支，然后删除该分支。Release分支: 当
develop分支上的项目准备发布时，从develop分支上创建一个新的release分支。新建的release分支只能进行质量测试，bug修复，文档生成等任务。不能再添加新的功能。这一系列任务完成后需要将release分支合并到master分支上，并根据版本号为master分支添加tag，然后将release分支合并到develop分支，最后删除该分支。Hotfix分支: 当
master分支中的产品出现需要立即修复的bug时，从master分支上创建一个新的hotfix分支，并在该分支进行bug修复。修复完成后需要将该分支合并到master分支和develop分支，并为master打上新的版本号tag，最后删除该分支。
在使用以上工作流时，有一点要万分注意，如果你是一个开发人员，那么 develop 分支和 master 分支你是没有权限操作的，也就是说你只能操作 feature 分支和 hotfix 分支。
结束语
我们通常知道这个规范后自己使用git的命令去实现这个规范就好了，但同时我们也可以通过可视化工具来完成以下步骤，比如现在使用比较多的 SourceTree
