主分支 master 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布
开发分支 dev 开发分支，个人将开发完成内容合并到此分支，供联调使用
功能分支 feature/20220708_login 新功能分支，某个功能点正在开发阶段
测试分支 release/test 测试分支
修复分支 hotfix/20220708_login_captcha_error 修复线上代码的bug
发布版本 将测试完成的功能打tag号 供上线使用 例如TAG-2022-08-01_21-03-22
一、命名目的
规范开发，保持代码提交记录，容易维护，方便事后算账，不背锅。
git分支结构清晰， 好上线，一旦出问题，版本可回退
二、 git 分支命名规范
git 分支分为集成分支、功能分支和修复分支，分别命名为 develop、feature 和 hotfix，均为单数。不可使用 features、future、hotfixes、hotfixs 等错误名称。
- master（主分支，永远是可用的稳定版本，不能直接在该分支上开发）
- develop（开发主分支，所有新功能以这个分支来创建自己的开发分支，该分支只做只合并操作，不能直接在该分支上开发）
- feature-xxx（功能开发分支，在develop上创建分支，以自己开发功能模块命名，功能测试正常后合并到develop分支）
- feature-xxx-fix(功能bug修复分支，feature分支合并之后发现bug，在develop上创建分支修复，之后合并回develop分支。
- PS:feature分支在申请合并之后，未合并之前还是可以提交代码的，所以feature在合并之前还可以在原分支上继续修复bug)
- hotfix-xxx（紧急bug修改分支，在master分支上创建，修复完成后合并到 master）
注意事项：
- 一个分支尽量开发一个功能模块，不要多个功能模块在一个分支上开发。
- feature 分支在申请合并之前，最好是先 pull 一下 develop 主分支下来，看一下有没有冲突，如果有就先解决冲突后再申请合并
本人命名规范
示例一``
例如：feature/20200305_screen大屏功能
例如：fixbug/20200424_screen_data_error修复大屏日期错误
例如：release/test测试分支
2. git 提交记录规范
每个 git commit 记录都需要按照固定格式，具体格式为：
第一行：作者: 功能模块名称（或 功能模块ID）
第二行：提交描述，中英文皆可
+ ：增加代码
* ：修改代码
- ：删除代码
master 主分支 对应线上，版本上线，开发人员将对应上线tag版本合并至master分支
release. 主分支 同 master 分支，预发环境通过之后，上线之前，合并 release 分支
dev-* 辅助分支 从 master 拉取，用于新需求(版本)开发 *号为版本号+期次号
bugfix-* 辅助分支 从 master 拉取，用于快速修复线上Bug *号为bug英文简称+期次号
release-* 辅助分支 从 master 拉取，用于确保当前版本是基于线上最新版本迭代，可处理与线上代码存在的冲突,任务辅助分支在测试环境通过之后，上预发环境之前，务必拉取一个release-* 分支 *号为对应的 dev-* 或 bugfix-* 的*
三、分支管理
需求（版本）开发 从 master 拉取 dev 分支
分支命名规则 ：类型 - 版本号
Tag命名规则： 类型 - 版本号 - 期次号
例子：
- 分支：
dev-v2.0.1 release-v2.0.1 - Tag:
dev-v2.0.1-102401 release-v2.0.1-102401
线上问题处理 从 master 拉取 bugfix 分支
分支命名规则：类型 - bug英文简称
Tag命名规则： 类型 - bug英文简称 - 期次号
- 例子：
分支： bugtfix-dateError release-dateError Tag: bugfix-dateError-102401 release-dateError-102401
https://www.cnblogs.com/yorkyang/p/9147309.html
https://www.cnblogs.com/ShaYeBlog/p/5575852.html
https://blog.csdn.net/fifteen718/article/details/80347550