master develop feature release tag hotfix

这一流程最大的亮点是考虑了紧急Bug的应对措施，整个流程显得过于复杂，所以在实施该方案前，需要对整个开发流程进行系统的学习。也需要借助Git flow等工具的辅助。需要注意的是，不允许feature分支没有经过测试就合并到develop分支。而是先创建release分支。

分支说明：

在Git flow 中，这两个分支至关重要，它们会贯彻整个流程始终，绝对不会被删除。

Master分支市场保持着软件可以正常运行的状态。由于要维护这一状态，所以不允许开发者直接对master分支的代码进行修改和提交。

其他分支的开发工作进展到可以发布的程度后，将会与master分支进行合并，并且这一合并只在发布成品时进行。发布时将会附加版本编号的Git标签。

Develop分支时开发过程中代码中心分支。与master分支一样，这个分支也不允许开发者直接进行修改和提交。

程序员要以develop分支为起点新建feature分支，在feature分支中进行新功能的开发或者代码的修正。也就是说develop分支维系着开发过程中的最新代码，以便程序员创建feature分支进行自己的工作。

Feature分支以develop分支为起点，是开发者直接更改代码发送提交的分支。开发流程：

1.从develop分支创建feature分支

2.从feature分支中实现目标功能

流程：develop ->feature/dev_20220921_拍照

在适当的时机删掉feature分支，如上线一个月之后。

从需要发布的feature创建release分支，在这个分支，我们只处理与发布前准备相关的提交，比如版本编号变更的元数据的添加工作。如果软件部署到预发布环境后测试出bug，相关修正也要提交到这个分支。

注意：该分支绝对不能包含需求变更或者功能变更等重大修正。这一阶段的提交数应该限制到最低。

Release分支发布之后，需要提交pull request合并到develop和master分支。

流程：feature1+feature2->release/release_5.3.0_20220901

Release分支发布上线之后，要在最新的commit里打上标签，标签格式为v版本号_年月日，比如：v5.4.0_20200901，是价位上线发布时间。

然后推送标签到远程仓库

下述情况需要创建hotfix分支

Release 版本中发现了bug或者漏洞

Develop分支正在开发新功能，无法面向用户进行发布

漏洞需要及早处理，无法等到下一次版本发布

假设出现bug的版本是1.0.0，修复bug后的版本至1.0.1

hotfix发布之后，提pull request 到develop和master分支，管理员审查通过后合并。

流程：v1.0.0->hotfix/hotfix问题名称_20220901 -> develop/master -> v1.0.1_20220910

在适当的时机删掉分支