GIT分支管理

GIT分支管理和代码提交规范

一、总体说明

• 版本管理⼯具：git

• 开发阶段划分：开发->测试->预发布->上线

• 环境：dev（开发）、test（测试）、release（预发布）、pro（正式）

• 代码分支：

  分支名称	分支用途	分支说明	分支示例
  master	线上环境分支	与线上代码保持⼀致的代码基线，上线时根据当前版本号打tag	master
  release-x.x.x	提测分支	达到提测标准的某版本代码	release-1.10.1
  dev-x.x.x	版本开发分支	已确定版本的开发分支	dev-1.10.1
  dev-x.x.x-xx	版本开发分支的拆分	指定的版本的拆分，方便多需求并行开发，开发完成合并到版本分支	dev-1.10.1-workorder
  feature-{MMdd}-xx	特性分支	迭代业务特性，业务特性上线后即可删除，⼀个特性可以在跨多个迭代上线	feature-1226-invoice
  hotfix-x.x.x	热修复分支	线上紧急问题热修复分支	hotfix-1.10.101

二、分支关系及生命周期图

三、日常开发过程与行为规范

复制代码版本需求：已确定版本的需求
非版本需求：未确定版本需求、开发优化需求（特性）
版本子任务：根据版本拆分的子任务
小任务：开发任务时间小于4小时的开发任务（需求或者线上非紧急bug）
热修复：线上紧急需要修复的BUG

1、开发任务

1.1、版本需求

• 版本子任务：开发负责人从master拉取开发分支dev-x.x.x（例如：dev-1.10.1），再将版本按照功能模块拆分为多个子分支dev-x.x.x-xx（例如：dev-1.10.1-workorder）。
• 小任务：直接在开发分支上进行开发

1.2、非版本需求

开发人员从master拉取特性分⽀，特性开发组成员都基于该分⽀开发，分⽀命名规范：feature-{MM-dd}-xx

2、 提测

2.1、版本需求

• 版本子任务：开发人员将子分支（dev-1.10.1-workorder）合并到开发分支（dev-1.10.1），再由开发负责人将开发分支（dev-1.10.1）合并到提测分支（release-1.10.1）
• 小任务：开发负责人将开发分支（dev-1.10.1）合并到提测分支（release-1.10.1）

2.2、非版本需求

自测并且联调通过，合并对应的feature分⽀到dev并push到远端（非版本需求合并到版本分支前，需要开发负责人和项目负责人进行确认）。

3、BUG修复

• 联调阶段BUG：在各自分支上进行修复
• 提测阶段BUG：在开发分支（dev-1.10.1）上进行修复，修复完成后，统一进行再次提测
• 线上普通BUG：在最近提测的开发分支（dev-1.10.1）上进行修复
• 线上紧急BUG：从master拉取一个hotfix分支（hotfix-1.10.001），修复完成后直接进行提测

4、上线

4.1、版本需求

• 测试达到上线标准，开发负责人再次检查release分支，确保release分支已经包含master分支和开发分支的所有功能
• 上线完成后，有开发负责人将release分支合并到master分支，并打tag（任何一次版本发布，必须打tag）

4.2、热修复

• 测试达到上线标准，开发负责人再次检查hotfix分支，确保hotfix分支已经包含master分支所有功能（hotfix期间，master分支可能有变动）
• 上线完成后，由开发负责人将hotfix分支（hotfix-1.10.001）合并到master分支和开发分支（dev-1.10.1），并打tag（任何一次版本发布，必须打tag）

四、代码提交规范

1、提交检查勾选（注意右边的红框）

• 阿里code检查
• 格式化代码
• 优化导入
• 执行代码分析
• 检查TODO

2、提交消息规范

用以下关键字开头：

• [add] 新增
• [modify] 修改
• [fix] 修复
• [delete] 删除

3、提交代码规范

1. 单次提交细粒度要足够小，并要确保功能的完整性
2. 代码提交前，先进行pull，避免无意义的merge，如下图

五、分支合并规范

1、合并

1.1、其它分支更新到所在分支

单击其它分支，选择“merge selected into current”

1.2、自己分支合并到其它的分支

1. 合并之前，执行第一步，确保自己分支已经包含目标分支全部功能
2. check out到目标分支，单击自己的分支，选择“merge selected into current”
3. 如有冲突，取消本次合并
4. 提交PR

2、冲突解决规范

1. 研发负责人和开发人员共同参与
2. 冲突的文件，idea提示合并完成之后，才能确认
3. 全部冲突文件解决完毕，才算完成合并
4. 合并完成之后，需要在本地进行编译成功，才能进行push

六、产品版本号定义

版本格式：采⽤三段式版本号，d.d.d{hotfix}

• 第⼀段：产品重⼤版本升级
• 第⼆段：产品中等版本升级
• 第三段：产品⽇常版本升级（3位数，后两位用于BUG修复）

比如： 线上产品版本号为：1.10.1

• 热修复的版本号为：1.10.101
• 热修复的分支名称为：hotfix-1.10.101

线上产品版本号为：1.10.101

• 热修复的版本号为：1.0.102
• 热修复的分支名称为：hotfix-1.10.102