代码分支管理规范

代码分支管理

1、产线分支：master（production）

产线打包分支只能合并测试验证并通过验收的开发分支。
禁止操作：

1.禁止合并未通过验收的分支
代码合并之前需要进行code-review，确认没有需要修改之后再合并提交
##/ 2、预发布（UAT环境）分支：stage
UAT环境分支属于待验收分支，可以合并通过自测的开发分支。
每次提交之前都需要校验是否合并最新的产线分支代码
禁止操作：
1.禁止合并未通过自测出现运行错误的分支。
2.禁止合并报错分支

3、开发分支：

从产线分支切出新的分支，每次push代码之前都需要检测是否合并最新的mater分支
示例：

git checkout -b feat/xxxx

1.迭代版本需求开发：
命名规范：
phase/vx.x.x，x.x.x表示版本号，比如phase/v1.0.0
2.功能需求开发：
命名规范：feat/feattureId_simpleFeatureName,示例：feat/indicator， feat/11020_indicator。
字段含义：
a. 如果存在需求单,feattureId表示需求单Id,用来追查所对应的需求
b. simpleFeatureName使用英文简单描述该需求
3.bug需求开发：
bugfix/bugId_bugName,示例:
bugfix/fix_header_component_layout
bugfix/20240430_fix_header_component_layout
字段含义：
a. 如果存在bug单，bugId表示bug单Id
b. bugName简单描述该bug
4.紧急修复需求开发：
hotfix/UUID_bugName,示例：hotfix/20240430_replace_old_tree_component
字段含义：
a. UUID可以使用时间日期表示，也可以使用bug单ID表示
b. bugName简单描述该bug

待完善功能：

1.在代码中配置限制规范
a. 限制本地master分支 merge 其他分支，需要在码云提交code review审核之后再合并代码
b. 本地非生产分支提交之前检查是否合并最新master分支
对小公司来说极其遥远的设想：
1.ai code-review，节省人工code-review效率，能够发现人工review可能发现不了的问题，实现自动化code-review，每次代码提交都会有ai辅助review代码，并且邮件提示当次push代码修改点，修改优化方案等。
a. 公司允许接入ai审核code，需要有人去做接入ai
b. 需要接入邮件系统，跨部门协作