VV采用标准的Git flow，下面将从工作流图与抽象模型两个方面，来描述与规范 Git flow。
并在此基础上给出vv 的 master分支，hotfix-分支，develop分支，release-分支，feat-分支和bugfix-分支的定义与上下文。
工作流图
1 永久分支：Master分支与Develop分支
1.1 Master分支上的Commit都有对应的Tag。
1.2 Develop分支与Master分支是两个永久存在的分支，从公Master拉取Develop分支。
1.3 Develop分支不直接合并到Master分支，其通过Release分支合并到Master分支。
1.4 Master分支与线上版本保持一致。
1.5 Develop分支是自动构建分支，它总是保有当前即将发布或是已经发布的代码，是确定的下一次将要通过Release分支合并到master上的代码。
2 临时分支Feature
2.1 当需要开发新的特性时，从Develop分支拉取Feature分支。
2.2 命名规范：
标准Git flow 认为Feature分支可以是，除以master, develop, release-, 和 hotfix-_ 开头的任何串。
在此我们规定，Feature分支命名规范以feat-开使。
2.3 生命周期：开发中存在，在合并到develop后或是丢弃后，便删除。
2.4 通常只在开发者的仓库中存在，origin中没有Feature分支。（不采纳这条限制，多人合作需要Feature上推到origin）
2.5 Feature分支做完后（做完是值完成了主体功能，完成了大部分测试与bug的修复，可以存在少量的非重要bug），确定为当前上线的版本后，便可合并回Develop, 合并完分支后一般会删点这个Feature分支，也可以保留。
到这里，一个Feature分支的生命周期便结束了。
3 临时分支Release
Release分支基于Develop分支创建，可以在Release分支上测试，修改Bug等。
同时，其它开发人员可以基于Develop开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，删除Release分支。
4 临时分支hotfix
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
Git Flow 抽象模型
在使用的过程中一定要注意到数据流的流动方向。
下面给出Git Flow 的抽象模型，让大家能更加直观的把握、灵活的运用于实践中。
Feature分支流程
1 当有新的特性需要开发时，从Develop分支拉取Feature分支。
2 Feature分支在经过开发、测试后，确定为当前即将发布版本之后，便可合并到Develop分支，并删除Feature分支。
3 向Develop分支合并后，创建对应的Release分支，这可以对应一个或是多个Feature。
4 在Release上完成次要bug修复、发版配置等之后，便可合并到Develop与Master（Master上的合并需要加上tag）。
hotfix分支流程 与 release分支流程
1 它们都具有两个合并分支，Develop分支与Master分支。
2 hotfix拉取于Master分支。
3 release拉取于Develop分支。
4 hotfix是为解决线上严重问题而生。
5 release是为特性发布、工程配置、少量bug测试等问题而生。
release过后常规bug修复
release发布前，该特性引入的常规bug是在其上修改的。
对于release发布后，或是其它特性引入的bug，我们引入以"bugfix-"为开头的新特性。
至此我们基本遵守了标准 Git Flow 开发模型。
做了一个扩充：引入以"bugfix-"为开头的新特性，支持release发布后在Develop上发现的bug常规bug。
做了一个限制：Feature分支命名规范以“feat-”开始。
完整的数据流图与命名规范
格式： prename_postname
如 hotfix-5.11 , feat-5.11 , release-5.11 （5.11 为版本或是特性名称）
bugfix-图片上传（针对功能命名） ， bugfix-5.11 （针对某版本或是特性命名）
master分支
master是项目第一个被创建的分支。
每一个向master的合并，都对应一个经过严格测试的主观稳定的线上版本。
它是hotfix-分支的上游分支。
hotfix-分支
当线上版本出现严重的bug时，需要从master上选取特定的tag拉取代码。
在完成测试具备上线条件后，在hotfix-分支上完成版本的发布。
经灰度发布后，先合并到master，再合并到develop分支。
这两个合并步骤是不可分的，是一个事务。亦可称为同时合并到master分支和develop分支。
develop分支
develop分支在git flow 中承担了最为复杂与重要的任务。
它是feat-分支、release-分支，和bugfix-分支的起点。
是代码的同步中心，其它任何分支，都是经过develop分支完成代码同步的。
feat-分支
feat-分支是研发分支，源于develop分支，终于develop分支。
在feat-分支完成所有的新功能研发，多少bug的修复与优化工作。
在确定为会在下一个版本发布时，便可以合并到develop分支。
在develop分支上有一个或是多个合并的未上线的feat-分支时，可以选择拉取release-分支，进入release阶段。
release-分支
release-分支承载了发布中项目的配置，一定bug的修复，优化等工作。
创建release-分支有两个目的：
尽快向develop分支合并确定的下版feat-分支，极大的提高了研发的并发度；
经测试、发布、审核，进入灰度后，直到确定为不再回滚正式发布后，合并到master与develop分支。
它维护了长时间窗口等待期，确保master与线上版本的一致。
bugfix-分支
可被视为特殊的feat-分支。
⚠️⚠️⚠️分支操作注意事项
KenChoi：为什么你应该停止使用 Git rebase 命令
只能对自己的私有分支做rebase操作。
凡涉及到几大共有分支（master, develop, release-, hotfix-_和 bugfix-）上的commit的合并,
必须使用merge，禁止使用rebase。严格禁止共有分支上的提交id变更。
其它分支可以使用rebase，合并到develop分支，但是只要提交到了develop，
所有的commit就属于develop分支，禁止再使用rebase操作。
问题：你好,我最近在尝试使用 git-flow 有一个问题我一直没有找到答案,问题: 在开发分支中开发完的功能在当前发布版本是不需要发布出去,不知道你有没有合适的处理方案,谢谢
单独拉出来一个分支，把目前不需要的提交用rebase删除 git rebase-i