Git仓库负责人

1. 标准产品业务包

   • Git账号开通及新账号建立，联系林昶
   • 各微服务及后端底层，联系李宗永
   • APS相关微服务，联系赵必蔚
   • 各PC微前端及前端底层，联系李嘉轩
   • 各移动端前端及移动端底座，联系张泽峯
   • 各组件库（包含PC端及移动端），联系冯炜晴

2. 国星交付

   • 各微服务，联系郭晓锋
   • 各微前端及移动端业务包，联系张泽峯

3. 华鑫交付

   • 各微服务及微前端，联系颜子维

4. 大湾区交付

   • 各微服务及微前端，联系赵必蔚

发版具体流程图

后端项目分支说明

工程名	git地址	版本	分支	默认分支
mbm-mom-common	http://192.168.175.208/dme/mbm-mom-common.git	2.0.0-SNAPSHOT	master>ver>sit>dev	dev
dme-sdk	http://192.168.175.208/dme/dme-sdk.git	2.0.1-SNAPSHOT	master>ver>sit>dev	dev
mbm-mom-framework	http://192.168.175.208/dme/mbm-mom-framework.git	2.0.1-SNAPSHOT	master>ver>sit>dev	dev
mbm-mom-sdk	http://192.168.175.208/dme/mbm-mom-sdk.git	2.0.2-SNAPSHOT	master>ver>sit>dev	dev
mbm-mom-public	http://192.168.175.208/dme/mbm-mom-public.git	2.0.1-SNAPSHOT	master>ver>sit>dev	dev
mbm-mom-kernel	http://192.168.175.208/dme/mbm-mom-kernel.git	2.0.0-SNAPSHOT	master>ver>sit>dev	dev
mbm-mom-smt-mes	http://192.168.175.208/dme/mbm-mom-smt-mes.git	2.0.0-SNAPSHOT	master>ver>sit>dev	dev
mbm-mom-tools	http://192.168.175.208/dme/mbm-mom-tools.git	2.0.0-SNAPSHOT	master>ver>sit>dev	dev
mbm-mom-eam	http://192.168.175.208/dme/mbm-mom-eam.git	2.0.0-SNAPSHOT	master>ver>sit>dev	dev

注意

1. 所有版本都升级为2.0.0-SNAPSHOT
2. dev分支是dev环境分布分支，对应devops-dev流水线
3. sit分支是多租户分布分支，对应devops-huawei-renter流水线
4. 所有开发都需要从sit分支拉一个中间分支，将代码合并到dev分支发布dev测试，测试通过；将中间分支代码合并到sit分支，发布多租户环境测试

前端项目分支说明

产品定位	平台	工程名	GIT 地址	分支	默认分支	工程说明	额外保留分支
研发	移动端	mbm-mom-app-ui	git@192.168.175.208:dme/mbm-mom-app-ui.git	master>ver>sit>dev	dev	统一移动端	join2
研发	PC 端	mbm-mom-admin-ui	git@192.168.175.208:dme/mbm-mom-admin-ui.git	master>ver>sit>dev	dev	统一门户
研发	PC 端	mbm-mom-designer-ui	git@192.168.175.208:dme/mbm-mom-designer-ui.git	master>ver>sit>dev	dev	【微前端】设计即服务
研发	PC 端	mbm-mom-devops-ui	git@192.168.175.208:dme/mbm-mom-devops-ui.git	master>ver>sit>dev	dev	【微前端】Devops	join2
研发	PC 端	mbm-mom-eam-ui	git@192.168.175.208:dme/mbm-mom-eam-ui.git	master>ver>sit>dev	dev	【微前端】设备管理	join2
研发（国星RGB）	PC 端	mbm-mom-led-mes-ui	git@192.168.175.208:dme/mbm-mom-led-mes-ui.git	master>ver>sit>dev	dev	【微前端】国星 RGB 项目
研发	PC 端	mbm-mom-public-ui	git@192.168.175.208:dme/mbm-mom-public-ui.git	master>ver>sit>dev	dev	【微前端】公共模块
研发	PC 端	mbm-mom-qms-spc-cfg-ui	git@192.168.175.208:dme/mbm-mom-qms-spc-cfg-ui.git	master>ver>sit>dev	dev	【微前端】SPC 基础配置前端
研发	PC 端	mbm-mom-qms-spc-ui	git@192.168.175.208:dme/mbm-mom-qms-spc-ui.git	master>ver>sit>dev	dev	【微前端】SPC 前端
研发	PC 端	mbm-mom-smt-mes-ui	git@192.168.175.208:dme/mbm-mom-smt-mes-ui.git	master>ver>sit>dev	dev	【微前端】SMT	join2
研发	PC 端	mbm-mom-tools-ui	git@192.168.175.208:dme/mbm-mom-tools-ui.git	master>ver>sit>dev	dev	【微前端】工治具	join2

注意

1. dev 分支是 dev 环境发布分支，对应 devops-dev 流水线
2. sit 分支是多租发布分支，对应 devops-huawei-renter 流水线
3. 所有开发都需要从 sit 分支拉一个功能分支（feature/xxx），将代码合并到 dev 分支发布 dev 测试，测试通过；将功能分支（feature/xxx）合并到 sit 分支，发布多租环境测试

开发及提交代码流程

(1) 拉分支

1. 每个功能分支要和业务确定好该分支下个版本的开发模型:  迭代模式、瀑布模式、敏捷模式 以及开发内容。
2. 功能分支(feature)命名规范：feature/时间/功能名称，例如：feature/20240904/qcOptimize；
3. 功能分支(feature) 由 项目管理员决定 是从 master 拉取还是 ver 拉取；
4. 推荐分支颗粒度细化，用merge而不是cherrypick合并功能；

(2) dev环境测试

1. 提测邮件发布之后，再将代码从当前功能分支 merge/cherrypick 至 dev分支
2. dev测试完成后，不会从 dev分支 直接合并至 join分支

(3) 联建环境测试

1. 功能在dev测试完成后，由当前 功能分支(feature) 管理员，在gitLab发起请求 合并至 join分支

(4) 发版

1. 遵守封版时间，封版之后，由项目管理员进行代码合并进ver分支，同时封板期间无法修改任何代码
2. 每次发版时会进行打tag标签，标签规则：版本号_pro_时间，例如：v1.2.0_pro_20240828；
3. 发版失败后，取消封板限制，由项目管理员决定是否保留发版内容或择期再次发版

(5) 归档

1. 发版成功后，由项目管理员进行归档操作，保证 master归档代码 是 等于 线上环境代码

(6) 私人分支管理

1. 自己私人建的功能分支(feature) ，自己定期删除或者维护，不能冗余大量的无用的分支
2. 私人分支不建议推送远程仓库
3. 私人功能分支合并进当前功能分支再推送至远程仓库

(7) Hotfix修复

1. 线上环境紧急BUG由 hotfix分支 进行修复性发版，不紧急的BUG跟随下一次迭代一起上线
2. hotfix分支 从 <归档完成>的 master分支 进行拉取
3. hotfix分支 代码修复完成后合并，联系项目管理员进行 join分支 代码合并进行测试
4. 测试完成后，由项目管理员 进行发hotfix版本，版本号应从 正常的 release 更改为 hotfix
5. 补丁修复BUG成功后，合并至master进行归档，并且合并至其他功能分支

特例仓库

mbm-mom-sdk

mbm-mom-common

mbm-mom-framework

作为底层支撑项目还是遵从之前dev单线分支模式进行开发，同时所有改动必须保证历史版本兼容性

注意

• SDK 项目需遵从开发守则（即：acl中的repo层进行逻辑处理，api层为华为接口调用），同时不得重构当前已有的方法。
• Framework 一般不会变动 ，改动完成后 需要在大群中进行说明改动内容以及@所有人

git commit 提交规范

在日常的开发工作中，我们通常使用 git 来管理代码，当我们对代码进行某项改动后，都可以通过 git commit 来对代码进行提交。

提示

• git 规定提交时必须要写提交信息，作为改动说明，保存在 commit 历史中，方便回溯。规范的 log 不仅有助于他人 review, 还可以有效的输出 CHANGELOG，甚至对于项目的研发质量都有很大的提升。
• 但是在日常工作中，大多数开发同事对于 log 信息都是简单写写，没有很好的重视，这对于项目的管理和维护来说，无疑是不友好的。

格式模板：

type [标识]+‘：’+[业务模块]+‘-’+具体页面/具体功能开发的描述，若是修复善治 bug，带上善治 bug id

type类型，需严格遵守

• 新增: 新增feature，新功能开发
• 修复: 修复bug，如修复禅道bug，带上禅道bug编码
• 文档: 仅仅修改了文档，如readme.md
• 样式: 仅仅是对格式进行修改，如逗号、缩进、空格等。不改变代码逻辑。
• 重构: 代码重构，没有新增功能或修复bug
• 移除: 删除部分无用文件。
• 测试: 测试用例，包括单元测试、集成测试。
• 更新: 改变构建流程、或者增加依赖库、工具等。
• 回滚: 版本回滚

//如：
[新增]:[工单模块]工单导入页面-工单导入接口联调
[新增]:[工单模块] 文件解析 && 文件保存
[修复]:[MRP分配方案] 1206 分配方案明细->需求筛选：新增、编辑，不显示目录

参考资料

Git 官网链接 (opens new window)

Git 文档 (opens new window)

GitFlow工作流 (opens new window)