开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天，点击查看活动详情
日常开发中，经历一个项目的上线，会伴随着各种分支的生成、以及会创建大量的分支来确保项目开发、多人开发。那么，怎样命名不同功能的分支呢？
1. 分支类型
首先，在我日常开发中，我一共会见到以下几种类型的分支:
- dev
- test
- pre
- master
- feature/xxx
- feature/epic-xxx
- release/xxx
- hotfix/xxx
- fix/xxx
前四个分支，会一直存在项目中，分别对应着开发环境、测试环境、预发环境和线上环境。
feature/xxx和feature/epic-xxx在日常开发中都是增加新功能，但是feature/epic-xxx是我们的开发主分支。
release/xxx分支是我们的预发布分支，当同一个项目有多个版本同时上线时，就需要该分支的存在了
hotfix/xxx当我们修复线上bug的时候，需要创建
fix/xxx用于日常开发中的bug修复，如在开发中，测试提出的bug，就需要我们使用该分支进行修复
2. 分支关系
介绍完了日常开发中，会遇到的分支，那么它们的关系是怎样的呢？ 我们从日常开发一个项目来说！
- 我们会首先从
master(原来的线上环境)切出本次的开发主分支feature/epic-xxx。 - 基于我们的开发主分支
feature/epic-xxx，根据我们的需求拆分，切出我们每个需求的开发分支feature/xxx进行本次的需求开发。 - 每次需求分支开发完成后，我们通过
pr(githup)、mr(gitlab)的方式将开发完成的需求合并到开发主分支feature/epic-xxx中。 - 所有需求开发完成后，我们将开发主分支
feature/epic-xxx合并到开发测试环境分支dev，进行自测。 - 自测通过后，我们将开发主分支
feature/epic-xxx合并到测试环境test，并通知测试同学提测。 - 测试通过后，我们将开发主分支
feature/epic-xxx合并到预发分支pre，进行最后一轮的测试。 - 预发测试通过后，我们所有的测试阶段就结束了，如果当天上线有多个需求同时上线，则需要创建预发布分支
release/xxx,将所有的需求合到该分支。 - 将预发布分支
release/xxx合并到master，并进行发布。如果是当天只有一个需求发布，将开发主分支feature/ecic-xxx直接合并到master进行发布就可以了。 - 如果遇到线上问题，需要紧急修复，我们基于线上分支
master切出分支hotfix/xxx进行线上bug修复。 - 如果在测试过程中，遇到bug，我们基于开发主分支
feature/epic-xxx切出分支fix/xxx进行bug修复。
3. 流程图
文字看起来，比较难看，下面简单画了一个图，供参考！！！
搭配文字，进行查看。
需要注意的地方，我们在项目开发中，一般情况下是不允许自己合并代码到开发主分支（feature/epic-xxx）、预发布分支(release/xxx)以及线上分支（master），这几个分支只允许mr的方式进行代码合并，并且开发主分支和master都是受保护分支，一般不允许危险操作（强推之类的）。
4. 总结
所有的分支命名都是为了更好的服务项目开发、需求开发。分支命名方式看起来多，但实际操作起来也还好。
每个公司根据自己的情况都会有自己的命名规范。各位可以一起交流一下。上面的是我遇到的分支命名规则，并且在日常开发中如何使用来维护多人开发，确保不会出错。
日常开中git的使用，以及一整套项目开发流程，可以看下我其他的文章，有好的idea可以一起讨论下。如果有更好的见解，欢迎指正！！！
