TAG1.0
hotfixbranch
（hotfix）分支用于给产品发布版本（releases）快速生成补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。
developbranch
Gitflow工作流使用两个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个TAG版本号。
b、功能分支【feature】
TAG1.1
c、发布分支【release】
1、发布后线上版本发现bug，从master分支拉取新的维护分支，修改完毕后马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
开发主管
feature 2branch
TAG2.0
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布（release）分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。
1、运维人员加配置、yaml等资源文件2、开发人员修改bug3、增加各种文档等4、发布成功后将改动变化合并到master，打上tag号5、发布成功后将改动合并到develop
b3
开发人员
b2
b1
releasebranch
每个新功能位于一个自己的分支，但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。
1、开发人员按照功能模块不同，拉取各种不同的功能分支。2、功能开发完毕后，合并到devlop分支
d、维护分支【hotfix】
masterbranch
运维、开发人员
feature 1branch
a、历史分支【master、devloper】
