此管理规范主要包括以下内容：

master、release、test、develop、feature、hotfix等分支的作用及使用场景

master，

作用：是项目的稳定版本。项目需要正式发布上线，必须要在master上，使用master的代码进行打包或部署。通常发布版本前，可以在master上创建标签（tag），标记此次版本的重要信息。严格管理规范下，只有主要管理者才拥有master的push、merge等权限。

release

作用：是预发布分支

来自：在规范的操作中，release一般从develop分支创建而来

去向：然后最终要合并到master和develop

注意：release不是唯一的，一般都是依据项目的版本来创建相应的release，习惯命名方式是：release-*，而且我们允许在release上进行一些小修改（如：修改发布版本号）

test

作用：是测试分支

来自：开发者将develop分支合并到test分支后

去向：最后需要将test分支合并回develop分支。

注意：将test分支交由测试人员使用。测试人员测试完成后，开发人员可以在test分支创建一个本地的test-*分支用户修复bug，然后将创建的test-*分支合并回test分支 （按道理来说一个版本有一个线上的测试分支）

develop

作用：是该项目主要的开发分支，此分支的代码是项目正在开发的代码，并且始终和master并行

来自：master

去向：master

注意：每次有新的版本开发，开发人员都应该从develop分支创建属于某个版本release分支或某个开发人员的feature分支。开发完成后，test都应该将分支合并回develop。

feature

作用：是功能分支，通常为即将开发或未来开发版开发新的功能，常用的命名规则是feature-*

来自：feature分支必须从develop分支创建出来（本地分支）

去向：并且最终必须（间接）合并回develop分支（流程是写完给合并到test测试分支没问题后，test在合并到develop分支）

hotfix

作用：是热修复分支，我们不需要hotfix，只有在线上代码存在待修复问题时，我们才会在master创建hotfix分支

来自：master

去向：master和develop

注意：开发人员在hotfix修改完bug后，测试人员直接在hotfix上测试。测试完成后，必须将其合并到master和develop，合并到master是为了进行发布，而合并到develop则是为了保持develop和master同步并行。以上操作都完成后，就可以删除hotfix分支。