中心基本规范：https://doc.gz.cvte.cn/git

研发部门规范：00_Git协同开发规范

一、分支管理

1.分支说明

• feat：功能开发分支
  • 粒度：专项、小专项、单个零散任务、可一起上线的几个零散任务
  • 命名：专项用中心立项的编号命名；单个零散任务用jira story编号命名；小专项/可一起上线的几个零散任务用jira epic/story编号命名，尽量用可囊括全部功能点的。如 feat/plm-1234
  • 开始开发时从最新的master分支checkout，push到远端，到功能上线后需删除远端的分支
  • 功能开发完成后合并到dev分支发布测试环境进行测试
  • 每周二前确认feat分支是否要在周三上线，如确认上线，则合并进sprint分支
  • feat分支的提交仅需包含当前feat对应的功能/专项所需的提交
  • 每月定时检查远端的feat分支，检查是否有做了的功能一直没发布的
  • feat分支可以rebase master分支，但禁止rebase test分支
  • 当两个并行开发的feature分支有代码依赖时，可以把依赖的代码cherry pick或者merge过来，若选择merge，则被依赖的分支要先上线，或者两个feature分支的功能一起上线
• fix: 修复缺陷分支
  • 非紧急上线的情况。开发完成后合并dev分支测试，然后同feat分支一起合并到sprint分支中等待周三发布
• dev：测试分支，最全的代码，对应测试环境，功能开发完成后合并到test分支进行部署测试
• sprint:  每周发布正式的预合并分支
  • 命名：sprint/plm-21-6-12，以jira的sprint名称命名
  • 每周三发布正式后删除对应sprint分支
  • feat分支确认发布正式后合并到sprint分支，周三发布时直接使用sprint分支合并到uat和prod
• uat：预发布分支，测试环境测试通过的代码，对应UAT环境
• prod：主干分支，测试和UAT均验证通过的代码，对应生产环境，在Gitlab开启Protected Branches。不允许直接提交代码，只从sprint分支合并过来
• master：主干分支，prod分支验证通过的代码。在发布正式环境后的第二天，从prod分支合并到master中，并打tag记录
• hotfix：缺陷分支，用于修复线上bug并紧急上线
  • 命名：hotfix/plm-5678，命名可以是jira任务编号或者bug描述
• chore：杂项分支。无jira任务的系统改动及优化可使用此分支，可直接以描述命名

二、提交规范（commit信息）

1.格式

动作, JIRA任务编号, 描述

2.动作

• feat：新增功能
• modify：修改
• delete：删除
• fix：Bug修复
• refactor：代码重构
• chore：杂项

3.示例

feat: plm-1234, 自动合成描述

三、简单示例

1.新建feat分支

按JIRA上的task编号或者story编号命名，分支命名示例：plm-3130 （或plm-3130-xxx）

开发人员可以在gitlab上新建远程分支，也可以在本地新建再push远程

2.开发、提交、合并到dev分支、测试

开发人员完成

3.开发人员将feat分支提MR合并到sprint分支

前提：分支功能已测试通过，已确认该分支功能需要发布

4.项目代码负责人review代码，审批MR

5.sprint分支合并到uat分支，UAT环境验证

项目代码负责人完成

6.sprint分支合并到prod分支，发布

项目代码负责人完成

6.prod分支合并到master分支，打tag

上线第二天确认正式环境没有问题后，将prod分支合并进master分支，并打tag

四、LTC项目git工作流

LTC2.0开发过程中，为了尽可能复用代码，减少代码冲突，使用如下工作流。