一、命名目的
规范开发,保持代码提交记录,容易维护,方便事后算账,不背锅
git分支结构清晰, 好上线,一旦出问题,版本可回退
以下是我总结的git 分支命名规范:
主分支 master 主分支,所有提供给用户使用的正式版本,都在这个主分支上发布
开发分支 dev ①供联调与合作开发 ②不能在dev开发
功能分支 feature/20220708_login 基于master分支创建的个人功能分支
测试分支 release/test 测试分支没有问题 合并到master分支
修复分支 hotfix/20220708_login_captcha 修复线上代码的bug
发布版本 将测试完成的功能打tag号 供上线使用 例如TAG-2022-08-01_21-03-22
本人命名规范
例如: feature/20200305_screen
大屏功能
例如: fixbug/20200424_screen_data_error
修复大屏日期错误
例如: release/test
测试分支
其它命令规则(自由发挥、见闻知意、且有一定规则即可)
分支命名规则 :类型 - 版本号 - 日期 - 功能 feature/v2-20220708-login
Tag命名规则: 类型 - 版本号 - 期次号(或日期) TAG-test-v2.0.1-20200212
分支命名规则: 类型 - 版本号 - 日期 - bug英文简称 release-v2.0.1-102401 TAG-2022-08-01
Tag命名规则: 类型 - 版本号 - 日期 - bug英文简称 - 期次号 hotfix/v2-20220708_login_captcha
二、 git 分支命名规范
master
:主分支①永远是可用的稳定版本,不能直接在该分支上开发 ②开发新功能时,永远从master创建一个新的feature-xxx保证和线上代码一致,进行新功能开发(不背锅) ③feature-xxx自测完毕,合并到develop供同事更新代码(自测不因自己代码bug或冲突影响他人开发) ④功能开发完毕,develop进行联调 ⑤联调无问题后,合并到test测试使用 ⑥测试无问题,在test分支上打上Tag(表示发布版本) ⑦将打有Tag版本上线,线上测试无误后 ⑧将Tag版本或者release/test合并到master分支 ⑨可以开始 迭代下一个版本 新功能
develop
:开发主分支①多人合作的开发分支,不能直接在dev开发; ②每个人开发feature-xxx合并develop供同事拉取 ③联调完毕推到test分支
feature-xxx
:功能开发分支①基于master 创建分支,以开发时间+功能模块命名 如:feature/20220708_login ②功能自测完毕后,先pull一下develop(防冲突),然后在feature-xxx合并到develop ③每个版本、每个人有自己独立功能分支
fixbug
:bug修复分支①如果线上出现bug,及时修复,基于master创建出的分支 ②命名规范:修复时间+bug问题(或功能) 如:fixbug/20220708_lock_release ③功能自测完毕后, 合并到test分支(前提test分支与线上一直,否则创建release辅助分支进行部署测试) ④测试完毕后,打上Tag号,等待发布 ⑤release/test合并到master分支
hotfix-xxx
:紧急bug修改分支同上
release
辅助分支主分支 同 master 分支,预发环境通过之后,上线之前,合并 release 分支(本人厂小,没用预发环境哈)
三、git 提交记录规范
每个 git commit 记录都需要按照固定格式,具体格式为:(本人每次仅写本次提交功能哈)
第一行:作者: 功能模块名称(或 功能模块ID)
第二行:提交描述,中英文皆可
+ :增加代码
* :修改代码
- :删除代码