git 分支命名规范

一、命名目的

规范开发，保持代码提交记录，容易维护，方便事后算账，不背锅
git分支结构清晰， 好上线，一旦出问题，版本可回退

以下是我总结的git 分支命名规范：

主分支     master   主分支，所有提供给用户使用的正式版本，都在这个主分支上发布
开发分支   feature/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）
	第二行：提交描述，中英文皆可
	　　+ ：增加代码
	　　* ：修改代码
	　　- ：删除代码