git分支命名规范
Git分支管理
简介
git分支只要有 主分支 和 其他分支。
主分支：主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。
其他分支：其他开发活动创建的分支，如hotfix分支（紧急修复），release（发布新版本）等分支
master分支
作用： master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state），是当前系统的稳定版本。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。
develop分支
作用：develop分支是保存当前最新开发成果的分支。也就是我们开发环境运行，测试环境部署的代码。通常这个分支上的代码也是可进行随时发布部署的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
合并：develop分支上的代码已实现了当前版本中所有的迭代开发的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
release分支
创建： 当develop分支上的代码已经开发完成，包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。注意：而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。
作用： release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
使用: 从develop分支派生，必须合并回develop分支和master分支
hotfix分支
创建：正式生产环境软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷，对软件进行紧急修复工作。从master分支上指定的TAG版本派生hotfix分支
作用：hotfix分支用来进行软件代码的紧急修复工作。hotfix分支与release分支十分相似，都可以产生一个新的可供在生产环境部署的软件版本。
使用: 从master分支派生，必须合并回develop分支和master分支
feature分支 （不常用）
feature分支（有时也可以被叫做“topic分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
其他介绍：
主分支 master 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布 开发分支 dev 多人合作的开发分支①每个人开发完成内容合并到此分支，供同事拉取②联调此分支上③联调完毕推到test分支 功能分支 feature/20220708_login 个人功能分支，某个功能点正在开发阶段(开发完成合并到dev分支) 测试分支 release/test 测试分支没有问题 合并到master分支 修复分支 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
